Stan Henderson created CURATOR-597:
--------------------------------------
Summary: Background exception was not retry-able or retry gave up
Key: CURATOR-597
URL: https://issues.apache.org/jira/browse/CURATOR-597
Project: Apache Curator
Issue Type: Bug
Components: Framework
Affects Versions: 5.1.0
Environment: curator-framework 5.1.0 where Zoo Servers 3.6.3 are
running in a docker container with CentOS Linux release 7.9.2009 (Core)
Reporter: Stan Henderson
I see a similar issue as https://issues.apache.org/jira/browse/CURATOR-538 with
curator-framework 5.1.0 where Zoo Servers are running in a docker container
with CentOS Linux release 7.9.2009 (Core)
In the tests I'm running, it does not appear to occur all of the time and does
not appear to cause anything to fail.
server.1=9.48.164.32:2888:3888:participant;0.0.0.0:2181
server.2=9.48.164.34:2888:3888:participant;0.0.0.0:2181
server.3=9.48.164.35:2888:3888:participant;0.0.0.0:2181
server.4=9.48.164.39:2888:3888:observer;0.0.0.0:2181
server.5=9.48.164.40:2888:3888:observer;0.0.0.0:2181
server.6=9.48.164.42:2888:3888:observer;0.0.0.0:218
Compatibility.java:116: return (address != null) ?
address.getAddress().getHostAddress() : "unknown";
14:56:26.943 [main-EventThread] ERROR
org.apache.curator.framework.imps.CuratorFrameworkImpl - Background exception
was not retry-able or retry gave up
java.lang.NullPointerException: null
at
org.apache.curator.utils.Compatibility.getHostAddress(Compatibility.java:116)
~[curator-client-5.1.0.jar:?]
at
org.apache.curator.framework.imps.EnsembleTracker.configToConnectionString(EnsembleTracker.java:185)
~[curator-framework-5.1.0.jar:5.1.0]
at
org.apache.curator.framework.imps.EnsembleTracker.processConfigData(EnsembleTracker.java:206)
~[curator-framework-5.1.0.jar:5.1.0]
at
org.apache.curator.framework.imps.EnsembleTracker.access$300(EnsembleTracker.java:50)
~[curator-framework-5.1.0.jar:5.1.0]
at
org.apache.curator.framework.imps.EnsembleTracker$2.processResult(EnsembleTracker.java:150)
~[curator-framework-5.1.0.jar:5.1.0]
at
org.apache.curator.framework.imps.CuratorFrameworkImpl.sendToBackgroundCallback(CuratorFrameworkImpl.java:892)
[curator-framework-5.1.0.jar:5.1.0]
at
org.apache.curator.framework.imps.CuratorFrameworkImpl.processBackgroundOperation(CuratorFrameworkImpl.java:649)
[curator-framework-5.1.0.jar:5.1.0]
at
org.apache.curator.framework.imps.WatcherRemovalFacade.processBackgroundOperation(WatcherRemovalFacade.java:152)
[curator-framework-5.1.0.jar:5.1.0]
at
org.apache.curator.framework.imps.GetConfigBuilderImpl$2.processResult(GetConfigBuilderImpl.java:222)
[curator-framework-5.1.0.jar:5.1.0]
at
org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:644)
[zookeeper-3.6.3.jar:3.6.3]
at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:563)
[zookeeper-3.6.3.jar:3.6.3]
I'm using ExponentialBackoffRetry(5000, 29, 60 * 1000 * 2) for the
CuratorFrameworkFactory retry policy.
/**
@param baseSleepTimeMs initial amount of time to wait between retries
@param maxRetries max number of times to retry
@param maxSleepMs max time in ms to sleep on each retry
*/
public ExponentialBackoffRetry(int baseSleepTimeMs, int maxRetries, int
maxSleepMs)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
