[
https://issues.apache.org/jira/browse/ZOOKEEPER-1436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13286114#comment-13286114
]
Mark Gius commented on ZOOKEEPER-1436:
--------------------------------------
I'd like to confirm my understanding of this patch, and propose a possible
useful extension that may be better off in its own ticket.
Confirm: this is purely a notification for the caller. The ZK client code is
still looping around trying to reconnect just as before. In other words, if I
ignore ZOO_TIMED_OUT_STATE events, the client behavior is unchanged.
Possible extension: For zookeeper server clusters which are dynamic, it can be
very useful to know before a possible EXPIRE event that the client is having
trouble connecting. This gives the caller of the client the chance to
re-generate their ZK endpoint list and attempt to recover their session on a
new set of hosts. I suppose this might expose itself as some sort of
ZOO_TIMEOUT_WARNING or such that fires when the client has been disconnected
for SESSION_EXPIRE / 2 or some such thing.
Otherwise, I really like this as it gives the caller more information with
which to make informed decisions.
> Add ZOO_TIMED_OUT_STATE sesion event to notify client about timeout during
> reconnection
> ---------------------------------------------------------------------------------------
>
> Key: ZOOKEEPER-1436
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1436
> Project: ZooKeeper
> Issue Type: Improvement
> Components: c client
> Affects Versions: 3.4.3
> Reporter: Thawan Kooburat
> Assignee: Thawan Kooburat
> Labels: patch
> Attachments: ZOOKEEPER-1436.patch, ZOOKEEPER-1436.patch
>
>
> The zookeeper c client knows how long its session will last, and periodically
> pings in order to keep that session alive. However, if it loses connection,
> it hops from ensemble member to ensemble member trying to reform the session
> - even after the session timeout expires.
> This patch at a new session event (ZOO_TIMED_OUT_STATE) that notifies the
> user that the session timeout has passed, and we have been unable to
> reconnect. The event is one-shot per disconnection and get generated from the
> C-client library itself. The server has no knowledge of this event.
> Example use cases:
> 1. Client can try to reconnect to a different set of observers if it unable
> to connect to the original set of observers.
> 2. Client can quickly stop acting as an active server, since other server may
> already taken over the active role while it is trying to reconnect.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
