Mailing-List: contact dev-help@curator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@curator.apache.org
Date: Fri, 10 Apr 2015 19:38:13 +0000 (UTC)
From: "Mike Drob (JIRA)" <jira@apache.org>
To: dev@curator.apache.org
Message-ID: <JIRA.12819594.1428564118000.57590.1428694693122@Atlassian.JIRA>
In-Reply-To: <JIRA.12819594.1428564118000@Atlassian.JIRA>
References: <JIRA.12819594.1428564118000@Atlassian.JIRA>
 <JIRA.12819594.1428564118331@arcas>
Subject: [jira] [Commented] (CURATOR-206) 2 clients aquired the same
 InterProcessLock?
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/CURATOR-206?page=3Dcom.atlassia=
n.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D144=
90228#comment-14490228 ]=20

Mike Drob commented on CURATOR-206:
-----------------------------------

Also, do you see client #0 throwing an exception after reconnect? Even thou=
gh client #0 thinks it has the lock, it is likely because it is still stuck=
 in the middle of your endless loop. If it ever tries to release the lock i=
t will throw an exception.

I imagine that proper use of Curator here would need to verify that you sti=
ll have the lock before doing something if there is a chance that that the =
lock might have expired. Alternatively, make the locks persistent using som=
ething like:

{code}
            final InterProcessMutex lock =3D new InterProcessMutex(client, =
LOCK_PATH, new StandardLockInternalsDriver()
            {
                @Override
                public String createsTheLock(CuratorFramework client, Strin=
g path, byte[] lockNodeBytes) throws Exception
                {
                    String ourPath;
                    if ( lockNodeBytes !=3D null )
                    {
                        ourPath =3D client.create().creatingParentsIfNeeded=
().withProtection().withMode(CreateMode.PERSISTENT).forPath(path, lockNodeB=
ytes);
                    }
                    else
                    {
                        ourPath =3D client.create().creatingParentsIfNeeded=
().withProtection().withMode(CreateMode.PERSISTENT).forPath(path);
                    }
                    return ourPath;
                }
            });
{code}

I wonder if this is something that would be good to just have as a standard=
 option.

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