[
https://issues.apache.org/jira/browse/CURATOR-392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16086863#comment-16086863
]
ASF GitHub Bot commented on CURATOR-392:
----------------------------------------
Github user lvfangmin commented on a diff in the pull request:
https://github.com/apache/curator/pull/205#discussion_r127384661
--- Diff:
curator-framework/src/main/java/org/apache/curator/framework/imps/EnsembleTracker.java
---
@@ -166,12 +166,26 @@ public static String
configToConnectionString(QuorumVerifier data) throws Except
StringBuilder sb = new StringBuilder();
for ( QuorumPeer.QuorumServer server :
data.getAllMembers().values() )
{
+ if ( server.clientAddr == null )
+ {
+ // Invalid client address configuration in zoo.cfg
+ continue;
+ }
if ( sb.length() != 0 )
{
sb.append(",");
}
- InetSocketAddress address =
Objects.firstNonNull(server.clientAddr, server.addr);
-
sb.append(address.getAddress().getHostAddress()).append(":").append(address.getPort());
+ InetAddress wildcardAddress = new
InetSocketAddress(0).getAddress();
+ String hostAddress;
+ if ( wildcardAddress.equals(server.clientAddr.getAddress()) )
--- End diff --
If the clientAddr is in IPv6 format, will this equal? Or we should also
check the Inet6Address, would be great if you can add a test case with IPv6
wildcard.
> 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)
