Return-Path: X-Original-To: apmail-curator-dev-archive@minotaur.apache.org Delivered-To: apmail-curator-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 9FFD817862 for ; Thu, 9 Apr 2015 07:28:15 +0000 (UTC) Received: (qmail 97250 invoked by uid 500); 9 Apr 2015 07:28:12 -0000 Delivered-To: apmail-curator-dev-archive@curator.apache.org Received: (qmail 97202 invoked by uid 500); 9 Apr 2015 07:28:12 -0000 Mailing-List: contact dev-help@curator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@curator.apache.org Delivered-To: mailing list dev@curator.apache.org Received: (qmail 97182 invoked by uid 99); 9 Apr 2015 07:28:12 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 09 Apr 2015 07:28:12 +0000 Date: Thu, 9 Apr 2015 07:28:12 +0000 (UTC) From: "Huahang Liu (JIRA)" To: dev@curator.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Updated] (CURATOR-206) 2 clients aquired the same InterProcessLock? MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/CURATOR-206?page=3Dcom.atlassi= an.jira.plugin.system.issuetabpanels:all-tabpanel ] Huahang Liu updated CURATOR-206: -------------------------------- Description:=20 When a curator client acquires an InterProcessMutex, it creates an ephemera= l node on zookeeper. But if we disconnect the network for some time long en= ough so that the ephemeral node expires, the thread that has the lock will = not get interrupted and still =E2=80=9Cthinks=E2=80=9D it has the lock. And= if an other curator client tries to acquire the lock with the same path, i= t will acquired the lock while the first client still =E2=80=9Cthinks=E2=80= =9D it has the lock. Is this a defect? Or is it by design and this is not a proper way to use cu= rator? The snippet to reproduce this behaviour is uploaded as the following gist:= =20 https://gist.github.com/huahang/e6ebf948804fd7ea7c13 Run the code and wait until client #0 gets the lock: Client #0 trying to acquire lock Client #1 trying to acquire lock Client #0 lock acquired Disconnect the network and reconnect after the ephemeral node expires, and = then the following output will show in the command line: Client #1 lock acquired was: 2 clients acquired the same InterProcessMutex? When a curator client acquires an InterProcessMutex, it creates an ephemera= l node on zookeeper. But if we disconnect the network for some time long en= ough so that the ephemeral node expires, the thread that has the lock will = not get interrupted and still =E2=80=9Cthinks=E2=80=9D it has the lock. And= if an other curator client tries to acquire the lock with the same path, i= t will acquired the lock while the first client still =E2=80=9Cthinks=E2=80= =9D it has the lock. Is this a defect? Or is it by design and this is not a proper way to use cu= rator? The snippet to reproduce this behaviour is uploaded as the following gist:= =20 https://gist.github.com/huahang/e6ebf948804fd7ea7c13 Run the code and wait until client #0 gets the lock: Client #0 trying to acquire lock Client #1 trying to acquire lock Client #0 lock acquired Disconnect the network and reconnect after the ephemeral node expires, and = then the following output will show in the command line: Client #1 lock acquired > 2 clients aquired the same InterProcessLock? > -------------------------------------------- > > Key: CURATOR-206 > URL: https://issues.apache.org/jira/browse/CURATOR-206 > Project: Apache Curator > Issue Type: Bug > Components: Recipes > Environment: java 1.7 on ubuntu linux > Reporter: Huahang Liu > > When a curator client acquires an InterProcessMutex, it creates an epheme= ral node on zookeeper. But if we disconnect the network for some time long = enough so that the ephemeral node expires, the thread that has the lock wil= l not get interrupted and still =E2=80=9Cthinks=E2=80=9D it has the lock. A= nd if an other curator client tries to acquire the lock with the same path,= it will acquired the lock while the first client still =E2=80=9Cthinks=E2= =80=9D it has the lock. > Is this a defect? Or is it by design and this is not a proper way to use = curator? > The snippet to reproduce this behaviour is uploaded as the following gist= :=20 > https://gist.github.com/huahang/e6ebf948804fd7ea7c13 > Run the code and wait until client #0 gets the lock: > Client #0 trying to acquire lock > Client #1 trying to acquire lock > Client #0 lock acquired > Disconnect the network and reconnect after the ephemeral node expires, an= d then the following output will show in the command line: > Client #1 lock acquired -- This message was sent by Atlassian JIRA (v6.3.4#6332)