[
https://issues.apache.org/jira/browse/CURATOR-392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15922928#comment-15922928
]
ASF GitHub Bot commented on CURATOR-392:
----------------------------------------
GitHub user Vile2539 opened a pull request:
https://github.com/apache/curator/pull/205
[CURATOR-392] Fixing connection string construction for wildcard client
addresses
The client address in Zookeeper can be a wildcard (0.0.0.0), and if this is
used by Curator, it will attempt to create a new connection to 0.0.0.0 instead
of the correct server address. It is also possible that no client address or
port is set, which should be counted as invalid by Curator, since the
appropriate information isn't contained in the data sent.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/Vile2539/curator CURATOR-392
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/curator/pull/205.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #205
----
commit 9b73d11bc03c6e37567e237e96c36cdf93e4ff66
Author: Kenco <[email protected]>
Date: 2017-03-13T20:51:42Z
Fixing connection string construction to ignore wildcard client addresses
----
> 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.3.15#6346)
