curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Cameron McKenzie (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CURATOR-110) LeaderLatch does not complete if it is started without a connection to ZooKeeper
Date Thu, 05 Jun 2014 22:41:01 GMT

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

Cameron McKenzie commented on CURATOR-110:
------------------------------------------

Yes, that's an interesting point actually. I'm not sure if it's easily fixed either, because
there's no guarantee that the ConnectionStateListener used by the LeaderLatch will receive
a CONNECTED event, because it may be started after a connection has already been established
by Curator.

One solution would be to only call reset() in the start() method of LeaderLatch if a connection
to ZooKeeper is already established, but I don't believe that it's currently possible to query
the internal connection state of Curator. This information is currently only available via
the ConnectionStateListener interface, and you don't find out the current state until the
next state change.

We would need to  modify the CuratorFramework interface to add a getConnectionState() method,
that would return the current connection state. I think that this is pretty useful regardless,
but I'm wondering if it's been thought of before and rejected for some reason. Thoughts?

> LeaderLatch does not complete if it is started without a connection to ZooKeeper
> --------------------------------------------------------------------------------
>
>                 Key: CURATOR-110
>                 URL: https://issues.apache.org/jira/browse/CURATOR-110
>             Project: Apache Curator
>          Issue Type: Bug
>          Components: Recipes
>    Affects Versions: 2.5.0
>            Reporter: Cameron McKenzie
>            Priority: Minor
>              Labels: connection, latch, leader
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> Given the following conditions:
> 1.) No connection is available to ZK
> 2.) A LeaderLatch is created and started
> 3.) All retries for the leader latch creating its ephemeral zNode have been exhausted.
> At this point the LeaderLatch will not begin functioning correctly when a connection
is established. This is due to it ignoring 'CONNECTED' connection state events (it only handles
RECONNECTED events).
> The fix should simply be a case of making the state handling for CONNECTED and RECONNECTED
the same.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message