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