[
https://issues.apache.org/jira/browse/CURATOR-7?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13614690#comment-13614690
]
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: https://issues.apache.org/jira/browse/CURATOR-7
> Project: Apache Curator
> Issue Type: Bug
> Reporter: Shevek
> Assignee: Jordan Zimmerman
>
> See https://github.com/Netflix/curator/issues/266
> 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: http://www.atlassian.com/software/jira
