Uploaded image for project: 'Couchbase Java Client'
  1. Couchbase Java Client
  2. JCBC-333

Views are having issues in access and validations

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.2
    • Component/s: None
    • Security Level: Public
    • Labels:
      None

      Description

      SDKD: Caused by: java.util.concurrent.ExecutionException: OperationException: SERVER: not_found Reason: missing

      SDKD: WARNING: Unknown exception encountered (for operation) future warnings will be suppressed
      SDKD: java.lang.RuntimeException: Failed to access the view

      No reviews matched the request. Check your Options in the drop-down menu of this sections header.

        Activity

        Hide
        deeptida Deepti Dawar added a comment -

        For all the logs and related information you can refer to the latest test results at -

        https://docs.google.com/a/globallogic.com/spreadsheet/ccc?key=0AmLvaJ8oRZ-TdGxtdExRVTBMNnhDb1hac3pFV3VrMHc#gid=0

        Show
        deeptida Deepti Dawar added a comment - For all the logs and related information you can refer to the latest test results at - https://docs.google.com/a/globallogic.com/spreadsheet/ccc?key=0AmLvaJ8oRZ-TdGxtdExRVTBMNnhDb1hac3pFV3VrMHc#gid=0
        Hide
        ingenthr Matt Ingenthron added a comment -

        Alk: In this test, we have a four node cluster and we're trying to remove two nodes from the cluster while under load. The Java client is getting a response from the cluster: The response seems to be a 404 =>
        not_found Reason: missing

        This isn't a new issue, but I don't think we expect to receive a 404 during node removal, do we?

        If you could help us understand what to expect here and reassign it, I'd appreciate it.

        Show
        ingenthr Matt Ingenthron added a comment - Alk: In this test, we have a four node cluster and we're trying to remove two nodes from the cluster while under load. The Java client is getting a response from the cluster: The response seems to be a 404 => not_found Reason: missing This isn't a new issue, but I don't think we expect to receive a 404 during node removal, do we? If you could help us understand what to expect here and reassign it, I'd appreciate it.
        Hide
        alkondratenko Aleksey Kondratenko (Inactive) added a comment -

        I don't have access to logs. But I think this is what happens.

        When bucket rebalance out completes we stop all per-bucket services on rebalanced out nodes for this bucket. Including it's capi_set_view_manager. This is different case from where node still has bucket instance but doesn't have any active vbuckets left (in which case you'll receive redirect).

        Let me note that as we've agreed in past there's 10 second delay after rebalance out of bucket and stopping of bucket services (and bucket instance in memcached). Which works fine for kv access because you send requests depending on vbucket map. But is not directly helping you for views access.

        Here's what you can do:

        *) never send view request to node without any active vbuckets. After all you do have vbucket map and it's reasonably easy

        *) on receiving 404 just retry with other node(s)

        Show
        alkondratenko Aleksey Kondratenko (Inactive) added a comment - I don't have access to logs. But I think this is what happens. When bucket rebalance out completes we stop all per-bucket services on rebalanced out nodes for this bucket. Including it's capi_set_view_manager. This is different case from where node still has bucket instance but doesn't have any active vbuckets left (in which case you'll receive redirect). Let me note that as we've agreed in past there's 10 second delay after rebalance out of bucket and stopping of bucket services (and bucket instance in memcached). Which works fine for kv access because you send requests depending on vbucket map. But is not directly helping you for views access. Here's what you can do: *) never send view request to node without any active vbuckets. After all you do have vbucket map and it's reasonably easy *) on receiving 404 just retry with other node(s)
        Hide
        ingenthr Matt Ingenthron added a comment -

        Michael: Can you please evaluate the comments from Alk here?

        Show
        ingenthr Matt Ingenthron added a comment - Michael: Can you please evaluate the comments from Alk here?
        Hide
        daschl Michael Nitschinger added a comment -

        Makes sense to me why it happens.

        ad 404) I originally had the 404's in my retry with backoff logic, but I had to remove it because we can't distinguish that from a garbage view name that the user puts in. If we would retry in that case, we would end up with timeouts instead of semantically correct "view not found" messages.

        ad active vbuckets) that sounds good and I think I can make that work pretty quickly for 1.2. If we pass on the vbucket locator to the view connection, we can verify that.

        I'll update this ticket and we can then hand it over to QE for re-testing.

        Show
        daschl Michael Nitschinger added a comment - Makes sense to me why it happens. ad 404) I originally had the 404's in my retry with backoff logic, but I had to remove it because we can't distinguish that from a garbage view name that the user puts in. If we would retry in that case, we would end up with timeouts instead of semantically correct "view not found" messages. ad active vbuckets) that sounds good and I think I can make that work pretty quickly for 1.2. If we pass on the vbucket locator to the view connection, we can verify that. I'll update this ticket and we can then hand it over to QE for re-testing.

          People

          • Assignee:
            daschl Michael Nitschinger
            Reporter:
            deeptida Deepti Dawar
          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Gerrit Reviews

              There are no open Gerrit changes