[
https://issues.apache.org/jira/browse/CURATOR-617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17430307#comment-17430307
]
Angad Singh commented on CURATOR-617:
-------------------------------------
Added a class file that specifies the use case and the behavior. When the first
call to unregisterService fails, there is an exception thrown that can be
handled. However, on the next call, no such exception is thrown. Please refer
to the startTest() method in the attached class file for the exact scenario.
> 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
> Attachments: ZookeeperTest.java
>
>
> 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)
