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

Sync support for healthCheck API up to sdk-rfc

    XMLWordPrintable

Details

    • Improvement
    • Status: Resolved
    • Major
    • Resolution: Fixed
    • None
    • 2.5.5
    • None
    • None
    • SDK 45: IPv6, HC, SDK 47: HC, Log Redact, SDK49: HC, Log Reda, CertAuth, SDK51: Tra-I, CertAuth, HC, SDK2: Log Red, Tracing I

    Description

      In anticipation of the coming sdk-rfc, please add volatile support for a health check resposne.  Per discussion, the format would be approximately…

      {
        "version" : 1,
        "services" : {
           "fts" : [
              {
                 "latency_us" : 877.909,
                 "remote" : "centos7-lx1.home.ingenthron.org:8094",
                 "local" : "127.0.0.1:54669",
                 "state" : "reconnecting",
                 "details" : "RECONNECTING, backoff for 4096ms from Fri Sep  1 00:03:44 PDT 2017"
              }
           ],
           "kv" : [
              {
                 "last_activity_us" : 1182000,
                 "remote" : "centos7-lx1.home.ingenthron.org:11210",
                 "local" : "127.0.0.1:54670",
                 "state" : "connected"
             }
           ],
           "n1ql" : [
              {
                 "latency_us" : 6217,
                 "remote" : "centos7-lx1.home.ingenthron.org:8093",
                 "local" : "127.0.0.1:54671",
                 "state" : "connected"
              }
           ],
           "views" : [
              {
                 "latency_us" : 45585,
                 "remote" : "centos7-lx1.home.ingenthron.org:8092",
                 "local" : "127.0.0.1:54672",
                 "state" : "connected"
              }
           ]
        }
      }

       

      Where the "state" field describes the current connection conditions as a FSM:

      • "new"
      • "connecting"
      • "authenticating"
      • "connected", normal case, everything operating
      • "disconnected", always indicated unexpectedly
      • "reconnecting"
      • "disconnecting", planned, if say the map changed or the cluster requested a graceful connection shut down; some requests may still be in flight
      • "timeout" the server wasn't able to reply to ping request in time. The time should be the same as for corresponding service request.

       Goal is for deployments to be able to efficiently/safely check the status of the cluster as the client perceives it.  Where possible, the results should amortize the checks already run internally.

      Attachments

        Issue Links

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

          Activity

            There are no commits yet on this issue.

            People

              daschl Michael Nitschinger
              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