curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CURATOR-247) Extend Curator's connection state to support SESSION_LOST
Date Sun, 23 Aug 2015 20:36:45 GMT

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

ASF GitHub Bot commented on CURATOR-247:
----------------------------------------

Github user dragonsinth commented on the pull request:

    https://github.com/apache/curator/pull/97#issuecomment-133928010
  
    Very cool.  Before I dive in, couple of high level questions.
    
    1) Are we able to precisely articulate the relationship between session lost and existing
watchers?  For example, an acceptable answer might be "When a session is lost, all outstanding
watchers will fire a lost event.  Afterwards, all watchers will be removed.  Client code should
create new watchers if the session is re-established.  If a connection can be re-established
before the session is lost, all watchers will remain active."
    
    2) 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?



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

Mime
View raw message