[
https://issues.apache.org/jira/browse/CURATOR-355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15566676#comment-15566676
]
Benjamin Jaton commented on CURATOR-355:
----------------------------------------
Let's note that the code you provided using the TestingCluster class cannot be
used to reproduce the behavior stated in the bug, as local connection will be
actively denied if the port is not open, whereas in the original example, the
TCP connection will timeout.
> 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)
