Github user cammckenzie commented on the pull request:
https://github.com/apache/curator/pull/92#issuecomment-177643755
This change probably doesn't make sense unless it's in the CURATOR 3.0
branch does it? With the state management in 2.X, the LOST event doesn't meant
that the session is lost, just that Curator has given up trying to reconnect
based on its retry policy. This could mean that the actual session has expired
or it could mean that the session is still alive.
On the Curator 3.0 branch @Randgalt reimplemented the way that state
management occurs for the LOST event. The default is now that LOST will be
published when Curator thinks that the session has been LOST (based on a timer
while disconnected), and this is now the default behaviour.
So, perhaps this can only be merged into 3.0? I don't think that the logic
will work based on the 2.x version of the codebase.
---
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.
---
