Uploaded image for project: 'Couchbase .NET client library'
  1. Couchbase .NET client library
  2. NCBC-1725

Increment causing VBucketBelongsToAnotherServer exception to bubble up instead of retrying

    XMLWordPrintable

Details

    • Bug
    • Status: Resolved
    • Major
    • Resolution: Fixed
    • None
    • 2.6.1
    • None
    • None
    • 1

    Description

      Seems a regression of NCBC-808.

      To reproduce:
      1- Set up a 3 node cluster with KV service on all.
      2- Remove one node and start rebalance.
      3- Immediately run the following code:

      while(true)
      {
          var result = bucket.Increment(Guid.NewGuid().ToString());
          if (result.Status == Couchbase.IO.ResponseStatus.VBucketBelongsToAnotherServer)
          {
              Console.WriteLine("dd");
          }
      }
      

      You will see that VBucketBelongsToAnotherServer bubbles up.

      Attachments

        Issue Links

          For Gerrit Dashboard: NCBC-1725
          # Subject Branch Project Status CR V

          Activity

            jmorris Jeff Morris added a comment -

            Thanks David Saadeh, I'll look into this asap. What SDK and CB version should I test with?

            jmorris Jeff Morris added a comment - Thanks David Saadeh , I'll look into this asap. What SDK and CB version should I test with?

            Jeff Morris Test case come off of Couchbase Server 4.1.2, and SDK 2.5.12. Probably affects other versions as well, have not tested. Thanks

            david.saadeh David Saadeh (Inactive) added a comment - Jeff Morris Test case come off of Couchbase Server 4.1.2, and SDK 2.5.12. Probably affects other versions as well, have not tested. Thanks

            I think I've found the issue;

            When dispatching synchronous Increment operations, we were manually determining the server and dispatching directly to it, with some custom response handling. For the most part, the process of selecting the server and handling the response, including error messages / setting status codes, is handled by the RequestExecutor layer. All the other sync & async versions of Increment & Decrement, for both Couchbase and Memcached, buckets used the configured request executor.

            The following Gerrit change set updates the sync Increment method use the request executor: http://review.couchbase.org/c/97401/

            mike.goldsmith Michael Goldsmith added a comment - I think I've found the issue; When dispatching synchronous Increment operations, we were manually determining the server and dispatching directly to it, with some custom response handling. For the most part, the process of selecting the server and handling the response, including error messages / setting status codes, is handled by the RequestExecutor layer. All the other sync & async versions of Increment & Decrement, for both Couchbase and Memcached, buckets used the configured request executor. The following Gerrit change set updates the sync Increment method use the request executor:  http://review.couchbase.org/c/97401/

            People

              mike.goldsmith Michael Goldsmith
              david.saadeh David Saadeh (Inactive)
              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