Github user dragonsinth commented on the pull request:
https://github.com/apache/curator/pull/97#issuecomment-133928010
Very cool. Before I dive in, couple of high level questions.
1) Are we able to precisely articulate the relationship between session
lost and existing watchers? For example, an acceptable answer might be "When a
session is lost, all outstanding watchers will fire a lost event. Afterwards,
all watchers will be removed. Client code should create new watchers if the
session is re-established. If a connection can be re-established before the
session is lost, all watchers will remain active."
2) Assume a timing discrepancy between the curator client and ZK server,
such that the client assumes a session is lost by timeout, but in a (racy) way,
the connection is successfully re-established to the server and the server does
not drop the session. Can we be sure to resolve this race, such that if
session lost events have already fired or started firing, the client forcibly
creates a new session instead of using the old one?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
