[
https://issues.apache.org/jira/browse/CURATOR-164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14505394#comment-14505394
]
ASF GitHub Bot commented on CURATOR-164:
----------------------------------------
Github user madrob commented on a diff in the pull request:
https://github.com/apache/curator/pull/72#discussion_r28805374
--- Diff:
curator-x-discovery/src/main/java/org/apache/curator/x/discovery/details/ServiceDiscoveryImpl.java
---
@@ -228,15 +234,18 @@ protected void
internalRegisterService(ServiceInstance<T> service) throws Ex
public void unregisterService(ServiceInstance<T> service) throws
Exception
{
String path = pathForInstance(service.getName(),
service.getId());
- try
- {
- client.delete().forPath(path);
- }
- catch ( KeeperException.NoNodeException ignore )
- {
- // ignore
+ synchronized(service) {
--- End diff --
Imagine the following sequence:
T1: reconnect()
T2: unregister(X)
T1: for each service in cache:
T1: register(X)
T2: services.remove(X)
T2: client.delete(X)
T1: client.create(X)
> 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)
