[
https://issues.apache.org/jira/browse/CURATOR-345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15452005#comment-15452005
]
Alex Rankin commented on CURATOR-345:
-------------------------------------
Looks like I found the correct documentation (in the 3.4 documentation):
https://zookeeper.apache.org/doc/trunk/zookeeperReconfig.html#sc_reconfig_clientport
It unfortunately isn't actually listed in the 3.5.1.alpha documentation, but
the value is the old clientPort value. This value apparently shouldn't be used
in the zoo.cfg, but it still can be without issue, so this bug is still valid.
> NPE in EnsembleTracker when starting Curator
> --------------------------------------------
>
> Key: CURATOR-345
> URL: https://issues.apache.org/jira/browse/CURATOR-345
> Project: Apache Curator
> Issue Type: Bug
> Components: Framework
> Affects Versions: 3.1.0, 3.2.0
> Environment: ZooKeeper 3.5.1-alpha
> Reporter: Alex Rankin
> Priority: Minor
>
> We're currently getting a NPE when running Curator 3.1.0 and 3.2.0 in our
> environment. I don't believe this was occurring before we upgraded to
> ZooKeeper 3.5.1-alpha and Curator 3.1.0.
> {code}
> java.lang.NullPointerException
> at
> org.apache.curator.framework.imps.EnsembleTracker.configToConnectionString(EnsembleTracker.java:171)
> ~[curator-framework-3.2.0.jar:3.2.0]
> at
> org.apache.curator.framework.imps.EnsembleTracker.processConfigData(EnsembleTracker.java:186)
> ~[curator-framework-3.2.0.jar:3.2.0]
> at
> org.apache.curator.framework.imps.EnsembleTracker.access$300(EnsembleTracker.java:50)
> ~[curator-framework-3.2.0.jar:3.2.0]
> at
> org.apache.curator.framework.imps.EnsembleTracker$2.processResult(EnsembleTracker.java:144)
> ~[curator-framework-3.2.0.jar:3.2.0]
> at
> org.apache.curator.framework.imps.CuratorFrameworkImpl.sendToBackgroundCallback(CuratorFrameworkImpl.java:835)
> [curator-framework-3.2.0.jar:3.2.0]
> at
> org.apache.curator.framework.imps.CuratorFrameworkImpl.processBackgroundOperation(CuratorFrameworkImpl.java:618)
> [curator-framework-3.2.0.jar:3.2.0]
> at
> org.apache.curator.framework.imps.WatcherRemovalFacade.processBackgroundOperation(WatcherRemovalFacade.java:152)
> [curator-framework-3.2.0.jar:3.2.0]
> at
> org.apache.curator.framework.imps.GetConfigBuilderImpl$2.processResult(GetConfigBuilderImpl.java:214)
> [curator-framework-3.2.0.jar:3.2.0]
> at
> org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:587)
> [zookeeper-3.5.1-alpha.jar:?]
> at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:499)
> [zookeeper-3.5.1-alpha.jar:?]
> {code}
> The problem is that the QuorumServer.clientAddr here is null. This seems to
> be filled by parsing the ZooKeeper server properties, which look something
> like:
> {quote}
> server.1=zoo1:2888:3888
> server.2=zoo2:2888:3888
> server.3=zoo3:2888:3888
> {quote}
> In the QuorumServer constructor, we parse each server line into its
> respective tasks. The clientAddr, however, is filled by splitting the line
> around a semicolon and taking the second part:
> {code}
> String[] serverClientParts = addressStr.split(";");
> ...
> if(serverClientParts.length == 2) {
> String[] e = splitWithLeadingHostname(serverClientParts[1]);
> if(e.length > 2) {
> throw new ConfigException(addressStr + " does not have the form
> server_config or server_config;client_config where server_config is
> host:port:port or host:port:port:type and client_config is port or
> host:port");
> }
> String hostname = e.length == 2?e[0]:"0.0.0.0";
> ...
> }
> {code}
> This suggests that the server string should be followed by a client host/port
> (or just port), e.g.:
> {quote}
> server.1=zoo1:2888:3888;2181
> server.2=zoo2:2888:3888;2181
> server.3=zoo3:2888:3888;localhost:2181
> {quote}
> I can't find anything in the ZooKeeper documentation about this though, and
> it isn't mandatory in the properties (so shouldn't throw a NPE).
> This occurs every time we start the server, but doesn't affect functionality,
> hence the Minor flag. It would be nice to know what exactly is expected here
> though, so we can get rid of the exception.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
