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

Views are having issues in access and validations

    XMLWordPrintable

    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

        Attachments

        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

                  PagerDuty