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

Jordan Zimmerman commented on CURATOR-355:
------------------------------------------

ConnectionTimeout is a Curator concept. You should set it to whatever you need. 
ZooKeeper fails a heartbeat after 2/3 of a session as you have seen.

> Curator client fails when connecting to read-only ensemble
> ----------------------------------------------------------
>
>                 Key: CURATOR-355
>                 URL: https://issues.apache.org/jira/browse/CURATOR-355
>             Project: Apache Curator
>          Issue Type: Bug
>          Components: Client
>    Affects Versions: 2.11.0
>            Reporter: Benjamin Jaton
>            Priority: Critical
>         Attachments: test2.log
>
>
> ZK is 3.5.1-alpha
> I have a 3 nodes ZK cluster , readonly mode is enabled.
> 2 nodes are down, so one of them (QA-E8WIN11) is in read-only (verified by 
> using the ZK API manually). All the machines of the ensemble can be pinged 
> from the client.
> I'm using this piece of code:
> {code}
>               Builder curatorClientBuilder = CuratorFrameworkFactory.builder()
>                               
> .connectString("QA-E8WIN11:2181,QA-E8WIN12:2181")
>                               
> .sessionTimeoutMs(45000).connectionTimeoutMs(15000)
>                               .retryPolicy(new RetryNTimes(3, 
> 5000)).canBeReadOnly(true);
>               CuratorFramework client = curatorClientBuilder.build();
>               client.start();
>               client.getZookeeperClient().blockUntilConnectedOrTimedOut();
>               System.out.println("Successfully established the connection 
> with ZooKeeper");
>               
>               client.getData().forPath("/");
>               System.out.println("Done.");{code}
> When curator pick the host that is UP first, it goes through very quickly. 
> When it picks the host that is down first (QA-E8WIN12), it seems to be stuck 
> at the getData() call for a very long time, and then eventually fail with a 
> ConnectionLossException. (see attached log)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to