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

Enhance intelligence of client to know about all nodes of a cluster for making REST connection

    Details

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

      Description

      If configured with a single host (a load balancer), the client may pause for everytime it loses this connection. The same thing happens when configured with a list of hosts and the client reaches the end of the list...it pauses before going back to the top.

      I don't think it's appropriate to ask for the client to constantly spin on trying to make a connection if in fact none can be made.

      Another solution to this would be to have the client be aware of ALL the servers in a cluster (which it gets via the vbucket map info) and be able to try all of them, and/or know which ones are alive so that it doesn't have to wait

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

        Activity

        Hide
        perry Perry Krug added a comment -

        This is also needed when trying to upgrade the entire cluster as IP addresses are changing (mostly in AWS)

        Show
        perry Perry Krug added a comment - This is also needed when trying to upgrade the entire cluster as IP addresses are changing (mostly in AWS)
        Hide
        perry Perry Krug added a comment -

        Matt, can this get added to 1.2 as well or is it being deferred?

        Show
        perry Perry Krug added a comment - Matt, can this get added to 1.2 as well or is it being deferred?
        Hide
        daschl Michael Nitschinger added a comment -

        Perry, whats the deal here?

        The reconfiguration is done with backoff (and sleep during backoff), so its not really consuming CPU time.

        Show
        daschl Michael Nitschinger added a comment - Perry, whats the deal here? The reconfiguration is done with backoff (and sleep during backoff), so its not really consuming CPU time.
        Hide
        perry Perry Krug added a comment -

        The deal is to enhance the client so that even if all of the bootstrap nodes become available (or are removed from the cluster) the running client still is able to communicate with the cluster and receive topology changes.

        Example:
        -4 node cluster with 1.1.1.1, 1.1.1.2., 1.1.1.3, 1.1.1.4.
        -1.1.1.1 and 1.1.1.2 are given to the java client as bootstrap nodes
        -Now, an upgrade is taking place and 1.1.1.1 and 1.1.1.2 are being swapped out for .5 and .6.
        -With the current implementation, the client would not be able to receive further topology updates
        -This enhancement is asking that even though .1 and .2 were used for bootstrap, .3 and .4 would be included within the internal list of the client so that when .1 and .2 go away, it can failover to .3 or .4 and continue working.

        Obviously a restart of the same client would fail because it couldn't reach .1 or .2, but this is understood and not what we're trying to achieve.

        Show
        perry Perry Krug added a comment - The deal is to enhance the client so that even if all of the bootstrap nodes become available (or are removed from the cluster) the running client still is able to communicate with the cluster and receive topology changes. Example: -4 node cluster with 1.1.1.1, 1.1.1.2., 1.1.1.3, 1.1.1.4. -1.1.1.1 and 1.1.1.2 are given to the java client as bootstrap nodes -Now, an upgrade is taking place and 1.1.1.1 and 1.1.1.2 are being swapped out for .5 and .6. -With the current implementation, the client would not be able to receive further topology updates -This enhancement is asking that even though .1 and .2 were used for bootstrap, .3 and .4 would be included within the internal list of the client so that when .1 and .2 go away, it can failover to .3 or .4 and continue working. Obviously a restart of the same client would fail because it couldn't reach .1 or .2, but this is understood and not what we're trying to achieve.
        Hide
        daschl Michael Nitschinger added a comment -

        Okay gotcha, I'll think this through.

        Show
        daschl Michael Nitschinger added a comment - Okay gotcha, I'll think this through.

          People

          • Assignee:
            ingenthr Matt Ingenthron
            Reporter:
            perry Perry Krug
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Gerrit Reviews

              There are no open Gerrit changes