Mailing-List: contact dev-help@curator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@curator.apache.org
Date: Tue, 21 Apr 2015 21:54:59 +0000 (UTC)
From: "Mike Drob (JIRA)" <jira@apache.org>
To: dev@curator.apache.org
Message-ID: <JIRA.12754424.1415699338000.67488.1429653299327@Atlassian.JIRA>
In-Reply-To: <JIRA.12754424.1415699338000@Atlassian.JIRA>
References: <JIRA.12754424.1415699338000@Atlassian.JIRA>
 <JIRA.12754424.1415699338981@arcas>
Subject: [jira] [Commented] (CURATOR-164) curator-x-discovery:
 unregisterService is not guaranteed to remove the service, due to
 reconnectListener concurrency issue
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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