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

Defer bootstrapping errors on buckets to first operation

    XMLWordPrintable

Details

    • Bug
    • Status: Resolved
    • Major
    • Resolution: Fixed
    • None
    • 3.0.0
    • None
    • None
    • 1
    • SDK1: GA and Priority List

    Description

      As per rfc contract, calling cluster.bucket must return the Bucket instance immediately and defer errors on the operation level. The way it looks right now suggests it is not doing that (looks like sdk2 where it potentially failed on I/O and not returned immediately)?

      Attachments

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

        Activity

          jmorris Jeff Morris added a comment -

          I am trying to find where this behavior is defined, the Bootstrapping RFC doesn't mention Collections. This is the portion for opening a bucket:

          Bucket Connection Sequence
          Upon receiving a request from the application to open a bucket for operations, the client must begin the process of opening a bucket connection.
          If the cluster object already has a set of connections which are established, the client MUST hijack these connections and perform a SELECT_BUCKET operation against them to upgrade the memcached connections to being bucket connections (rather than cluster connections). Following this hijacking, any periodic configuration fetches being performed at the cluster level must be stopped (since the cluster object no longer owns any connections to perform those requests against).
          If the cluster does not own any connections (too early, or another connected bucket already stole them), a new set of connections should be established instead. This should follow the same semantics that are used for a cluster connection with the addition that should all connections to the cluster fail using memcached, the client should revert back to HTTP streaming, as described below.
          Once connections are established for the bucket connection, the client should begin refreshing the configuration periodically under the same semantics used above for cluster level connections.

          Things come to mind if everything was deferred completely, like how would views work since they are a bucket level construct?

          jmorris Jeff Morris added a comment - I am trying to find where this behavior is defined, the Bootstrapping RFC doesn't mention Collections. This is the portion for opening a bucket: Bucket Connection Sequence Upon receiving a request from the application to open a bucket for operations, the client must begin the process of opening a bucket connection. If the cluster object already has a set of connections which are established, the client MUST hijack these connections and perform a SELECT_BUCKET operation against them to upgrade the memcached connections to being bucket connections (rather than cluster connections). Following this hijacking, any periodic configuration fetches being performed at the cluster level must be stopped (since the cluster object no longer owns any connections to perform those requests against). If the cluster does not own any connections (too early, or another connected bucket already stole them), a new set of connections should be established instead. This should follow the same semantics that are used for a cluster connection with the addition that should all connections to the cluster fail using memcached, the client should revert back to HTTP streaming, as described below. Once connections are established for the bucket connection, the client should begin refreshing the configuration periodically under the same semantics used above for cluster level connections. Things come to mind if everything was deferred completely, like how would views work since they are a bucket level construct?
          jmorris Jeff Morris added a comment -

          Foundational RFC:

          Also, as outlined in the bootstrapping RFC, the bootstrap process itself is lazy w.r.t error propagation. Errors are deferred into the operation, other than illegal config options on Cluster.connect. This makes sure that the user only has to have error handling in a minimal amount of places.

          jmorris Jeff Morris added a comment - Foundational RFC: Also, as outlined in the bootstrapping RFC, the bootstrap process itself is lazy w.r.t error propagation. Errors are deferred into the operation, other than illegal config options on Cluster.connect. This makes sure that the user only has to have error handling in a minimal amount of places.

          People

            jmorris Jeff Morris
            daschl Michael Nitschinger
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Gerrit Reviews

                There are no open Gerrit changes

                PagerDuty