[
https://issues.apache.org/jira/browse/CURATOR-247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14708607#comment-14708607
]
ASF GitHub Bot commented on CURATOR-247:
----------------------------------------
Github user Randgalt commented on the pull request:
https://github.com/apache/curator/pull/97#issuecomment-133976670
> 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?
This isn't an issue because when the LOST state is generated the current
client is also closed so the session will expire in any event.
> Extend Curator's connection state to support SESSION_LOST
> ---------------------------------------------------------
>
> Key: CURATOR-247
> URL: https://issues.apache.org/jira/browse/CURATOR-247
> Project: Apache Curator
> Issue Type: Sub-task
> Components: Framework
> Affects Versions: 2.8.0
> Reporter: Jordan Zimmerman
> Assignee: Jordan Zimmerman
> Fix For: 3.0.0
>
>
> Currently, Curator has a connection state for LOST that confuses users. It
> does _not_ mean that the session is lost. Instead it means that the retry
> policy has given up retrying. Introduce a new connection state that roughly
> corresponds to the ZooKeeper session expiring. Possibly require that clients
> request this support via a new new builder method in CuratorFrameworkFactory
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
