[ https://issues.apache.org/jira/browse/CURATOR-164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14505864#comment-14505864 ]
Mike Drob commented on CURATOR-164: ----------------------------------- The new solution includes a lot more synchronization than I had originally. Also, you don't need state to be an atomic reference if you're only accessing it inside of a sync block. That said, if we're adding in all of these changes with the sync blocks in place, then I don't see what the additional complexity buys us. Can we split this into two issues - solve the concurrency in this one, and then a new one to rework the logic around using holders so that we can review it separately? > 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 > Assignee: Jordan Zimmerman > Priority: Critical > Fix For: 2.8.0 > > > 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)