curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benjamin Jaton (JIRA)" <>
Subject [jira] [Commented] (CURATOR-355) Curator client fails when connecting to read-only ensemble
Date Tue, 11 Oct 2016 16:37:20 GMT


Benjamin Jaton commented on CURATOR-355:

Is there a documentation somewhere that talks about what connectionTimeout means for Curator?
I thought it was the timeout of the connection to a specific node.

Also I don't think ZK fails after 2/3 of a session. From my tests it seems to fail at (sesstionTimeout
/ nbServersInConnectionString).

> Curator client fails when connecting to read-only ensemble
> ----------------------------------------------------------
>                 Key: CURATOR-355
>                 URL:
>             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 =;
> 		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

View raw message