[ 
https://issues.apache.org/jira/browse/CURATOR-247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14707620#comment-14707620
 ] 

Jordan Zimmerman commented on CURATOR-247:
------------------------------------------

Implementation notes so far:
* It makes more sense to alter the meaning of the current LOST state than 
adding a new state
* Now is a good time to fix a very old problem. Every API call bottlenecks 
through RetryLoop.callWithRetry(). The first thing this method does is 
client.internalBlockUntilConnectedOrTimedOut(). If the connection doesn't 
succeed, the actual API call will fail and the retry policy will signal a retry 
which again calls client.internalBlockUntilConnectedOrTimedOut(). This is not 
reasonable behavior and makes having a true LOST session event more difficult. 
So, if the new behavior is enabled, a timeout during connection will 
immediately throw KeeperException.ConnectionLossException without retrying
* ConnectionStateManager has been altered so that the event poller will post a 
LOST state if the configured session timeout elapses
* When the new behavior is enabled, the background sync() call is no longer 
made when the Disconnect is received. It is no longer necessary as the 
* ConnectionStateManager is now watching for session timeout.
* The Base testing class now runs each test twice. Once in the pre 3.0 mode and 
once with enableSessionExpiredState set to true

> 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)

Reply via email to