curator-dev mailing list archives

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


Cameron McKenzie commented on CURATOR-110:


As for 'wait until connected' logic, off the top of my head.
-Have the CuratorFramework expose a getConnectionState() method so we can check the current
connection state.

Wait logic would be something like:
-Add connection state listener
-Check current state via curator framework
-If connected proceed as usual
-If not connected, block on some state variable (an AtomicBoolean perhaps, or maybe an AtomicReference
to a ConnectionState, which would allow a bit more flexibility, to wait for a particular state)
-In the connection state listener, each time there's a connection state change, update the
state variable, and notify everyone blocking on it.

I've implemented something similar for test cases to try and avoid putting sleeps in the code.
Instead it blocks until a certain connection state is reached before proceeding..

> LeaderLatch does not complete if it is started without a connection to ZooKeeper
> --------------------------------------------------------------------------------
>                 Key: CURATOR-110
>                 URL:
>             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
> 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

View raw message