[
https://issues.apache.org/jira/browse/CURATOR-392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16089156#comment-16089156
]
ASF GitHub Bot commented on CURATOR-392:
----------------------------------------
Github user Randgalt commented on a diff in the pull request:
https://github.com/apache/curator/pull/205#discussion_r127618052
--- Diff:
curator-framework/src/test/java/org/apache/curator/framework/imps/TestReconfiguration.java
---
@@ -313,6 +313,38 @@ public void testNewMembers() throws Exception
}
}
+ @Test
+ public void testConfigToConnectionStringNormal() throws Exception
+ {
+ String config =
"server.1=10.1.2.3:2888:3888:participant;10.2.3.4:2181";
+ String configString =
EnsembleTracker.configToConnectionString(toQuorumVerifier(config.getBytes()));
+ Assert.assertEquals("10.2.3.4:2181", configString);
+ }
+
+ @Test
+ public void testConfigToConnectionStringNoClientAddr() throws Exception
+ {
+ String config = "server.1=10.1.2.3:2888:3888:participant;2181";
+ String configString =
EnsembleTracker.configToConnectionString(toQuorumVerifier(config.getBytes()));
+ Assert.assertEquals("10.1.2.3:2181", configString);
+ }
+
+ @Test
+ public void testConfigToConnectionStringWildcardClientAddr() throws
Exception
+ {
+ String config =
"server.1=10.1.2.3:2888:3888:participant;0.0.0.0:2181";
--- End diff --
@Vile2539 CURATOR-3.0 branch has been discontinued. "master" is now what
used to be CURATOR-3.0
> Zookeeper Ensemble Get Incorrect Address
> ----------------------------------------
>
> Key: CURATOR-392
> URL: https://issues.apache.org/jira/browse/CURATOR-392
> Project: Apache Curator
> Issue Type: Bug
> Components: Framework
> Affects Versions: 3.2.1
> Environment: ZooKeeper 3.5.1-alpha
> Reporter: Alex Rankin
>
> I've noticed an issue with Curator 3.2.1 which relates to the fix from
> CURATOR-345 (also reported by me).
> When we would reconnect after losing connection to Zookeeper (due to network
> issues), our services would always have the wrong connection string, and
> never manage to reconnect to the Zookeeper cluster. Assuming that 10.1.2.3 is
> our zookeeper server, and we have two scenarios (with different zoo.cfg
> files) we were seeing the following results when a reconnection was
> established:
> {quote}
> *Scenario 1:* ClientCnxn - Opening socket connection to server
> 0.0.0.0/0.0.0.0:2181.
> *Scenario 2:* ClientCnxn - Opening socket connection to server
> 10.1.2.3/10.1.2.3:2888.
> {quote}
> Obviously these are both undesirable connection strings, as both are wrong.
> The issue arises in the EnsembleTracker.processConfigData() when we reconnect
> to Zookeeper. The config coming from zookeeper is in [the
> format|https://zookeeper.apache.org/doc/trunk/zookeeperReconfig.html#sc_reconfig_clientport]:
> {quote}
> server.<positive id> = <address1>:<port1>:<port2>\[:role\];\[<client port
> address>:\]<client port>
> {quote}
> As we can see, both \[:role\] and \[<client port address>:\] are optional.
> Hence, the following string is perfectly valid:
> {quote}
> server.1=10.1.2.3:2888:3888:participant;2181
> {quote}
> When Zookeeper sends this, it defaults the clientAddress to 0.0.0.0, so we
> retrieve the following value in EnsembleTracker:
> {quote}
> server.1=10.1.2.3:2888:3888:participant;0.0.0.0:2181
> {quote}
> The resulting connection string, therefore, turns in to 0.0.0.0:2181 instead
> of 10.1.2.3:2181, and Curator creates a new ZooKeeper to connect to that IP -
> which obviously never works.
> In the second scenario, our connection string looks a bit different. It is
> wrong according to the docs, but is valid:
> {quote}
> server.1=10.1.2.3:2888:3888:participant
> {quote}
> Now, this is missing the client port and address. That means that the
> resulting string from the EnsembleTracker is 10.1.2.3:2888 - which isn't
> desired. Including the port would just lead to the above scenario.
> From what I can see, the EnsembleTracker.configToConnectionString() method is
> the issue here:
> {code}
> InetSocketAddress address = Objects.firstNonNull(server.clientAddr,
> server.addr);
>
> sb.append(address.getAddress().getHostAddress()).append(":").append(address.getPort());
> {code}
> In the above cases, both the server.Addr and server.clientAddr values are
> wrong. We also prefer the value of clientAddr for some reason, which doesn't
> look right to me (given that it can be 0.0.0.0 or 127.0.0.1).
> It seems to me that Curator should use server.Addr.getHostAddress() with
> server.clientAddr.getPort(). When the clientAddr is missing, however, I'm not
> sure what should be done.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
