[
https://issues.apache.org/jira/browse/CURATOR-355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Jaton updated CURATOR-355:
-----------------------------------
Description:
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)
was:
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)
> 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)
