curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jordan Zimmerman (JIRA)" <>
Subject [jira] [Commented] (CURATOR-7) Session ids not preserved if EnsembleProvider has changed the ensemble
Date Tue, 26 Mar 2013 23:47:15 GMT


Jordan Zimmerman commented on CURATOR-7:

Possible implementations (off the top of my head): HandleHolder could be changed to hold the
session info. It would get assigned by ConnectionState when the session is established. ZookeeperFactory
needs additional arguments for optional session info. If the HandleHolder has session info,
it passes it to the ZookeeperFactory. ConnectionState would need to handle KeeperState.Expired
in this case (though it may just handle it normally - you'd need to test for that).
> Session ids not preserved if EnsembleProvider has changed the ensemble
> ----------------------------------------------------------------------
>                 Key: CURATOR-7
>                 URL:
>             Project: Apache Curator
>          Issue Type: Bug
>            Reporter: Shevek
>            Assignee: Jordan Zimmerman
> See
> InterProcessMutex, LeaderLatch, etc use an ephemeral node. If ZooKeeper gives a Disconnected
event, the native client reconnects with the same session id, and the ephemeral node is preserved.
If the ensemble changes at any point before a Disconnect, Curator's ConnectionState#checkState()
calls handleNewConnectionString(), which constructs a new native ZK client, discarding the
previous session id, and losing all locks.
> This can be expensive.
> Can ConnectionState be made to preserve the session id, or be more conservative about
discarding the entire native client on a Disconnected event?
> Clarifications:
> An ensemble change (e.g. adding a new node to a cluster) does not mean that all session
ids are now invalid. The next network glitch should not break locks.
> There is no assumption in this description that the reconfiguration and the glitch/disconnection
were related - they need not be.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message