Details
-
Improvement
-
Resolution: Fixed
-
Major
-
None
-
None
-
None
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
- mentioned in
-
Page Loading...