curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dragonsinth <>
Subject [GitHub] curator pull request: [CURATOR-247] Extend Curator's connection st...
Date Sun, 23 Aug 2015 20:36:38 GMT
Github user dragonsinth commented on the pull request:
    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 or file a JIRA ticket
with INFRA.

View raw message