[ https://issues.apache.org/jira/browse/CURATOR-355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Benjamin Jaton updated CURATOR-355: ----------------------------------- Summary: Curator client fails when connecting to read-only ensemble (was: Curator client hangs when connecting to read-only ensemble) > 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)