[jira] [Created] (CURATOR-597) Background exception was not retry-able or retry gave up

["Stan Henderson (Jira)" <ji...@apache.org>]

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)