[
https://issues.apache.org/jira/browse/CURATOR-402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16083519#comment-16083519
]
ASF GitHub Bot commented on CURATOR-402:
----------------------------------------
Github user lvfangmin commented on a diff in the pull request:
https://github.com/apache/curator/pull/216#discussion_r126874138
--- Diff:
curator-framework/src/main/java/org/apache/curator/framework/imps/EnsembleTracker.java
---
@@ -170,8 +170,10 @@ public static String
configToConnectionString(QuorumVerifier data) throws Except
{
sb.append(",");
}
- InetSocketAddress address =
Objects.firstNonNull(server.clientAddr, server.addr);
-
sb.append(address.getAddress().getHostAddress()).append(":").append(address.getPort());
+ InetSocketAddress clientAddress = server.clientAddr;
--- End diff --
After ZooKeeper 3.5, if the zoo.cfg is in old format which has clientPort
and server list being defined, then the clientAddr will be 0.0.0.0, which
shouldn't be used as the server hostAddress. CURATOR-392 reported some issues
similar, and it has handled this case.
> Curator should not use QuorumServer.addr when updating the connect string
> dynamically
> -------------------------------------------------------------------------------------
>
> Key: CURATOR-402
> URL: https://issues.apache.org/jira/browse/CURATOR-402
> Project: Apache Curator
> Issue Type: Bug
> Affects Versions: 3.2.1, 3.3.0
> Reporter: Stig Rohde Døssing
> Assignee: Jordan Zimmerman
>
> https://issues.apache.org/jira/browse/CURATOR-345 made a change to
> EnsembleTracker to read the QuorumServer.addr in case the
> QuorumServer.clientAddr field is null. This doesn't seem right to me.
> When the Zookeeper cluster is configured with the new clientPort syntax
> (http://zookeeper.apache.org/doc/r3.5.3-beta/zookeeperReconfig.html#sc_reconfig_clientport),
> the clientAddr is correctly set:
> {code}
> 19:54:10.691 [main-EventThread] ERROR
> org.apache.curator.framework.imps.EnsembleTracker - Getting clientAddr
> /0.0.0.0:2181 and server addr localhost/127.0.0.1:2888
> 19:54:10.691 [main-EventThread] ERROR
> org.apache.curator.framework.imps.EnsembleTracker - Getting clientAddr
> /0.0.0.0:2182 and server addr localhost/127.0.0.1:2889
> 19:54:10.691 [main-EventThread] ERROR
> org.apache.curator.framework.imps.EnsembleTracker - Getting clientAddr
> /0.0.0.0:2183 and server addr localhost/127.0.0.1:2890
> {code}
> If the ensemble is configured with the old clientPort property, the
> clientAddr fields will be null:
> {code}
> 19:59:23.801 [main-EventThread] ERROR
> org.apache.curator.framework.imps.EnsembleTracker - Getting clientAddr null
> and server addr localhost/127.0.0.1:2888
> 19:59:23.801 [main-EventThread] ERROR
> org.apache.curator.framework.imps.EnsembleTracker - Getting clientAddr null
> and server addr localhost/127.0.0.1:2889
> 19:59:23.801 [main-EventThread] ERROR
> org.apache.curator.framework.imps.EnsembleTracker - Getting clientAddr null
> and server addr localhost/127.0.0.1:2890
> {code}
> Before https://issues.apache.org/jira/browse/CURATOR-345, this was okay,
> since using the old clientPort property just wound up making the
> EnsembleTracker.configToConnectionString method return an empty string, which
> effectively disables Curators ability to update the connection string.
> With the new behavior, the connect string will be updated to the server
> addresses (i.e. the peer ports) if the clientAddr fields are null, which will
> result in Curator being unable to reconnect if the Zookeeper instance needs
> to be replaced.
> As far as I'm aware the client has no use for the Zookeeper peer ports, so
> the change from https://issues.apache.org/jira/browse/CURATOR-345 should
> probably be reverted.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
