[
https://issues.apache.org/jira/browse/CURATOR-247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14708590#comment-14708590
]
ASF GitHub Bot commented on CURATOR-247:
----------------------------------------
Github user cammckenzie commented on the pull request:
https://github.com/apache/curator/pull/97#issuecomment-133959712
Nice work Jordan,
I just had a quick preliminary look through stuff and I had one
observation. For the timing stuff that checks if we've been in a SUSPENDED
state for long enough for the server to have timed out the connection, it's
using the session timeout specified in the builder.
Isn't there some sort of negotiation when connecting to Zookeeper in
regards to session timeout? I.e. It's possible for Zookeeper to specify that a
different session timeout will be used rather than the one that the client
wants?
> 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)
