[
https://issues.apache.org/jira/browse/CURATOR-164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14206538#comment-14206538
]
Rasmus Berg Palm commented on CURATOR-164:
------------------------------------------
Hi. I unfortunately only have a test of our own higher level classes. I'll give
you some pseudo code though.
{code:title=PesudoCodeTest.java|borderStyle=solid}
//repeat test a couple of times until race-condition occurs.
server = new TestingServer();
discovery = new ServiceDiscoveryImpl();
discovery.registerService("foo")
server.stop();
server.restart();
discovery.unregisterService("foo")
assert disovery.queryByName("foo").isEmpty()
{code}
If you wish to provoke the error more frequently use a slow serializer as the
code will wait in the registerInternal for the serializer.
> curator-x-discovery: unregisterService is not guaranteed to remove the
> service, due to reconnectListener concurrency issue
> --------------------------------------------------------------------------------------------------------------------------
>
> Key: CURATOR-164
> URL: https://issues.apache.org/jira/browse/CURATOR-164
> Project: Apache Curator
> Issue Type: Bug
> Components: Framework
> Affects Versions: 2.7.0
> Reporter: Rasmus Berg Palm
> Priority: Critical
>
> In ServiceDiscoveryImpl:
> When unregistering a service, the reconnect listener might fire while
> deleting the path.
> This can cause a condition where the delete finishes successfully, the
> service is removed from services, and then the reRegisterServices completes
> successfully and the service is added back in ZK and in services, end result
> being that the service was not removed, even though unregisterService did not
> throw any exceptions.
> Essentially the use of the internal 'services' cache makes for a nightmare of
> concurrency issues. I put this as critical as the library it's really not
> usable IMO.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
