[
https://issues.apache.org/jira/browse/CURATOR-164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rasmus Berg Palm updated CURATOR-164:
-------------------------------------
Description:
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.
was:
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.
Priority: Critical (was: Major)
Summary: curator-x-discovery: unregisterService is not guaranteed to
remove the service, due to reconnectListener concurrency issue (was:
unregisterService is not guaranteed to remove the service, due to
reconnectListener concurrency issue)
> 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)
