Mailing-List: contact dev-help@curator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@curator.apache.org
Date: Tue, 11 Nov 2014 15:20:34 +0000 (UTC)
From: "Rasmus Berg Palm (JIRA)" <jira@apache.org>
To: dev@curator.apache.org
Message-ID: <JIRA.12754424.1415699338000.469541.1415719234864@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=14206538#comment-14206538 ] 

Rasmus Berg Palm commented on CURATOR-164:
------------------------------------------

Hi. I unfortunately only have a test of our own higher level classes. I'll give you some pseudo code though. 

{code:title=PesudoCodeTest.java|borderStyle=solid}
//repeat test a couple of times until race-condition occurs.
server = new TestingServer();
discovery = new ServiceDiscoveryImpl();

discovery.registerService("foo")

server.stop();
server.restart();

discovery.unregisterService("foo")
assert disovery.queryByName("foo").isEmpty()

{code}

If you wish to provoke the error more frequently use a slow serializer as the code will wait in the registerInternal for the serializer.

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