curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Drob (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CURATOR-164) curator-x-discovery: unregisterService is not guaranteed to remove the service, due to reconnectListener concurrency issue
Date Tue, 21 Apr 2015 21:24:01 GMT

    [ https://issues.apache.org/jira/browse/CURATOR-164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14505793#comment-14505793
] 

Mike Drob commented on CURATOR-164:
-----------------------------------

The JVM has been pretty good about biased locking in recent years, so if there's no contention
over the sync block that it is only very slightly slower than not having the sync block at
all. I'll take a look at your changes in more detail later, but my first impression is that
the complexity is much higher. I don't know what kind of performance requirements we have
on this chunk, but reconnect code has never struck me as a critical section. I'd favor clarity
and maintainability here, if given the choice.

> 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)

Mime
View raw message