[
https://issues.apache.org/jira/browse/CURATOR-439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16445888#comment-16445888
]
Jordan Zimmerman commented on CURATOR-439:
------------------------------------------
I don't understand what the bug is here. Curator status "STARTED" does not mean
you are connected. You must look at Curator's ConnectionState. Please see
details here: [http://curator.apache.org/errors.html]
No - you do not have to close and restart the curator instances. The only
reason to recreate the Curator Instances is if the ip/port of the ZooKeeper
instances changes. If they don't change, there is no need to ever re-create the
Curator instances. You can see copious tests in the Curator code base where
this is proven.
Also, from this Jira's description, it would be _wrong_ to check isConnected
before making requests. This, itself, might cause an outage. Curator internally
manages the ZooKeeper connection. If you don't make any requests when
isConnected is false you might never get a successful connection.
You can see from the Curator example code
([http://curator.apache.org/curator-examples/index.html)] that there's no need
for a lot of what you are doing.
> CuratorFrameworkState STARTED, but ZookeeperClient not connected
> ----------------------------------------------------------------
>
> Key: CURATOR-439
> URL: https://issues.apache.org/jira/browse/CURATOR-439
> Project: Apache Curator
> Issue Type: Bug
> Components: Framework
> Affects Versions: 3.2.1
> Reporter: Alex Rankin
> Priority: Major
>
> I recently ran into an issue on some of our nodes caused by network issues
> between a service and Zookeeper. I have been unable to recreate them as of
> yet, but I'm still trying.
> *+Setup+*
> 5x services using Curator 3.2.1 to talk to Zookeeper 3.5.3 cluster (also 5
> nodes).
> Network issues caused the services to disconnect from Zookeeper.
> There's a check in our code to see if the Zookeeper connection is available
> before sending a request:
> {quote}public boolean isConnected() \{
> return curatorFramework.getZookeeperClient().isConnected();
> \}
> {quote}
> After the network issues resolved, we noticed that all calls to Zookeeper
> from 4 of the services were still failing (the fifth was fine). Checking the
> logs, we saw that {{CuratorFramework.getState()}} was reporting the state as
> STARTED, but {{curatorFramework.getZookeeperClient().isConnected();}} was
> returning false. Restarting the service fixed everything, but I want to
> obviously avoid this issue in future.
> *+Problem+*
> I couldn't find any documentation stating whether the
> {{CuratorZookeeperClient.isConnected()}} should be used, or if
> {{CuratorFramework.getState() == CuratorFrameworkState.STARTED}} (the
> functionality of the deprecated {{CuratorFramework.isConnected()}}) would be
> the better check, or if these should both be equivalent, and there's a bug
> that let one be true while the other was false.
> If my own check is wrong, and I shouldn't be using
> {{CuratorZookeeperClient.isConnected()}}, then I can easily fix that. I
> wanted to check the expected behaviour before diving too deep into this, in
> case this is normal and I am just using Curator incorrectly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
