[
https://issues.apache.org/jira/browse/CURATOR-617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angad Singh updated CURATOR-617:
--------------------------------
Comment: was deleted
(was: Adding a code snippet with comments to make the use-case a little clearer:
{code:java}
@Override
public void deregister(IServiceDefsInfo serviceDefs) throws
ServicesManagerException {
List<IServiceInfo> servicesInfo = serviceDefs.getServicesInfos();
for (IServiceInfo serviceInfo : servicesInfo) {
String serviceID = prepareServiceID(serviceInfo);
ZookeeperRegistrationInfo regInfo = regInfoMap.remove(serviceID);
if(zookeeperRegistrationInfo != null) {
try {
//unregisterService method called here
serviceDiscovery.unregisterService(regInfo.getServiceInstance());
} catch (Exception e) {
this.regInfoMap.put(serviceID, regInfo);
ServicesManagerException registryException = new
ServicesManagerException(e);
//exception flagged as retryable if
KeeperException.ConnectionLossException
registryException.setRetryable(isRetryable(e));
throw registryException;
/*the catch block is never hit during the second retry
because the Entry object is already removed from the
internal services cache*/
}
}
}
}{code}
)
> UnregisterService Method in ServiceDiscoveryImpl is non-Idempotent in case of
> connection-failure
> ------------------------------------------------------------------------------------------------
>
> Key: CURATOR-617
> URL: https://issues.apache.org/jira/browse/CURATOR-617
> Project: Apache Curator
> Issue Type: Bug
> Affects Versions: 5.1.0
> Environment: Windows 10, 64-Bit
> Reporter: Angad Singh
> Assignee: Jordan Zimmerman
> Priority: Major
>
> The unregisterService( ) method in ServiceDiscoveryImpl throws an unhandled
> KeeperException.ConnectionLossException the first time it is invoked while
> the server connection is down. The next time, however, the service has
> already been removed from the internal _services_ cache. Hence the
> internalUnregisterService function does not proceed since the entry is null
> the second time around.
> We are not using the blockUntilConnected option, and instead are trying to
> implement a local retry mechanism. We are dependent upon the
> ConnectionLossException to be thrown, in order to catch and evaluate it
> before retrying with an exponential back-off.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
