You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@curator.apache.org by Jordan Zimmerman <jo...@jordanzimmerman.com> on 2014/10/01 02:46:47 UTC

Re: revocation not working

There are a number of problems:

* The docs are not clear on this, but makeRevocable() must be called BEFORE the lock is acquired. Please submit a Jira/PR to fix the doc.
* In your test, Revoker.attemptRevoke was using the incorrect path. It must be the path of the lock, so: "Revoker.attemptRevoke(client2, ipMutex.getLockPath());”
* InterProcessMutex keeps track of the thread that owns the lock. So, the lock.release(); in your revoker won’t work. I suggest using InterProcessSemaphoreMutex instead.

-JZ


On September 30, 2014 at 4:19:58 PM, Singer, Jill (jill.singer@pearson.com) wrote:

short:  I want to create a lock with one client and release it with another; so I am trying to use revocation for that end.  It isn't working.  more details (and my code) are below.
any help is appreciated!



long:  have a system where one thread (with its own client) sets the first lock (update),
            then a second thread (with a client that may or may not be the same as the original client)
            will set a second lock; then do some work, then release that lock, and then release the first lock

            this code simulates two threads by having two different clients get locks.

            the second client is unable to revoke the lock from the first client, however.  the 'revocation listener' is never triggered.
            I have scoured the web and not found examples.

            this code assumes that you have a zookeeper server running on your local host at port 2181

            ideally, I'd also like to look up from somewhere else real quick to see if the lock is in place, but perhaps 
            an acquire with a very short timeout (5 milliseconds) would accomplish that.

           also, is  it a good idea to reap away locks after releasing them?  (to not clog up the system?)

thanks

-Jill

ps:  also posted on stack overflow.

I'll cross-post answers if I have them.
>>>>>>>>>>>>>
import java.util.Collection;
import java.util.List;
import java.util.concurrent.TimeUnit;
import org.apache.curator.RetryPolicy;
import org.apache.curator.framework.CuratorFramework;
import org.apache.curator.framework.CuratorFrameworkFactory;
import org.apache.curator.framework.recipes.locks.InterProcessMutex;
import org.apache.curator.framework.recipes.locks.RevocationListener;
import org.apache.curator.framework.recipes.locks.Revoker;
import org.apache.curator.retry.ExponentialBackoffRetry;

public class MultipleClientExample {


    /*entry point
     */
    public static void main(String[] args){

        RetryPolicy retryPolicy = new ExponentialBackoffRetry(1000, 3);
        String zookeeperConnectionString = "127.0.0.1:2181";
        CuratorFramework client = CuratorFrameworkFactory.newClient(zookeeperConnectionString, retryPolicy);
        client.start();

        try {
            System.out.println("testing locks....");

            InterProcessMutex ipMutex = new InterProcessMutex(client, "/mpx-updates/guid123/update");

            boolean acquired = ipMutex.acquire(3, TimeUnit.SECONDS);
            System.out.println("got the lock(update)?" + acquired);

            RevocationListener<InterProcessMutex> rl = new MyRevocationListener();

            ipMutex.makeRevocable(rl);

            InterProcessMutex ipMutex2 = new InterProcessMutex(client, "/mpx-updates/guid123/swap");
            boolean a2 = ipMutex2.acquire(3, TimeUnit.SECONDS);
            System.out.println("got the lock(swap)?" + a2);

            System.out.println("got the first lock in this process? " + ipMutex.isAcquiredInThisProcess());

            // make a new client; see if it can get the lock!
            CuratorFramework client2 = CuratorFrameworkFactory.newClient(zookeeperConnectionString, retryPolicy);
            client2.start();

            InterProcessMutex ipMutex1Retry = new InterProcessMutex(client2, "/mpx-updates/guid123/update");
            boolean a3 = ipMutex1Retry.acquire(3, TimeUnit.SECONDS);
            System.out.println("got the lock(retry/update) ?" + a3);

            System.out.println("got the first lock in this process? " + ipMutex1Retry.isAcquiredInThisProcess());

            Revoker.attemptRevoke(client2, "/mpx-updates/guid123/update");
            a3 = ipMutex1Retry.acquire(3, TimeUnit.SECONDS);
            System.out.println("AGAIN: got the lock(retry/update) ?" + a3);

        } catch (Exception e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
        }

    }

    public class MyRevocationListener implements RevocationListener<InterProcessMutex> {

        /*
         * (non-Javadoc)
         * 
         * @see org.apache.curator.framework.recipes.locks.RevocationListener#revocationRequested(java.lang.Object)
         */
        @Override
        public void revocationRequested(InterProcessMutex lock) {

            //this seems to never be called 

            Collection<String> participantNodes = null;

            try {
                System.out.println("revocation was requested....");
                System.out.println("ick ick revocation requested....");
                participantNodes = lock.getParticipantNodes();
                lock.release();
                System.out.println("revoked lock at path: " + participantNodes);
            } catch (Exception e) {
                System.out.println("problem revoking lock with path: " + participantNodes + "; it was not revoked");
            }

        }

    }
}


Re: revocation not working

Posted by "Singer, Jill" <ji...@pearson.com>.
so when you say "submit a pull request";
you mean to do a fix and then submit it for review?

thanks

-Jill

(or else at least write up an issue of the problem in a jira ticket,
correct?)

On Wed, Oct 1, 2014 at 11:27 AM, Jordan Zimmerman <
jordan@jordanzimmerman.com> wrote:

> PR refers to a “Pull Request”. See here:
> https://cwiki.apache.org/confluence/display/CURATOR/Submitting+Pull+Requests
>
> -JZ
>
>
> On October 1, 2014 at 10:07:22 AM, Singer, Jill (jill.singer@pearson.com)
> wrote:
>
> I can get the path from:  getParticipantNodes();
>
> also, I can apparently 'release' the lock by just deleting the node:
>   ZKPaths.deleteChildren(client2.getZookeeperClient().getZooKeeper(),
> "/mpx-updates/guid123/update", false);
>
> and then you don't even have to get the full node path.
>
> it feels a little like a hack, but it works.
>
> a "PR" with improvements:  this means a specific email to a specific
> person?
>
> (nothing relevant in this list: http://en.wikipedia.org/wiki/PR#Computing)
>
> -Jill
>
>
>
>
>
>
>
> On Wed, Oct 1, 2014 at 10:53 AM, Jordan Zimmerman <
> jordan@jordanzimmerman.com> wrote:
>
>>  * Damn - looks like getLockPath() is protected. That should be
>> corrected. For now, create a subclass that has a new method that returns
>> the lock path.
>>
>>  * the  InterProcessSemaphoreMutex does not allow revoking; so how will
>> that help?
>>
>>  Damn again. Instead, you’ll need to interrupt the thread that owns the
>> lock.
>>
>> I apologize about the lack of features here. Apparently, this hasn’t
>> been used very much. A PR with improvements would be appreciated.
>>
>> -JZ
>>
>> On October 1, 2014 at 9:44:13 AM, Singer, Jill (jill.singer@pearson.com)
>> wrote:
>>
>>  Jordan-
>>
>>     thanks for the advice!
>>
>> Here are my follow-up questions:
>>
>> * I can't find the 'getLockPath()"  method on the InterProcessMutex or  InterProcessSemaphoreMutex
>> class
>>  (I looked here: https://curator.apache.org/apidocs/index.html and
>> couldn't find a 'getLockPath()" method anywhere (the docs are version
>> 2.5.1-snapshot, btw)
>> (I am using curator version 2.5.0)
>>
>>  * the  InterProcessSemaphoreMutex does not allow revoking; so how will
>> that help?
>>
>> On Tue, Sep 30, 2014 at 8:46 PM, Jordan Zimmerman <
>> jordan@jordanzimmerman.com> wrote:
>>
>>>  There are a number of problems:
>>>
>>>  * The docs are not clear on this, but makeRevocable() must be called
>>> BEFORE the lock is acquired. Please submit a Jira/PR to fix the doc.
>>>  * In your test, Revoker.attemptRevoke was using the incorrect path. It
>>> must be the path of the lock, so: "Revoker.attemptRevoke(client2,
>>> ipMutex.getLockPath());”
>>>  * InterProcessMutex keeps track of the thread that owns the lock. So,
>>> the lock.release(); in your revoker won’t work. I suggest
>>> using InterProcessSemaphoreMutex instead.
>>>
>>>  -JZ
>>>
>>>
>>> On September 30, 2014 at 4:19:58 PM, Singer, Jill (
>>> jill.singer@pearson.com) wrote:
>>>
>>>   short:  I want to create a lock with one client and release it with
>>> another; so I am trying to use revocation for that end.  It isn't working.
>>>  more details (and my code) are below.
>>> any help is appreciated!
>>>
>>>
>>>
>>> long:  have a system where one thread (with its own client) sets the
>>> first lock (update),
>>>             then a second thread (with a client that may or may not be
>>> the same as the original client)
>>>             will set a second lock; then do some work, then release that
>>> lock, and then release the first lock
>>>
>>>             this code simulates two threads by having two different
>>> clients get locks.
>>>
>>>             the second client is unable to revoke the lock from the
>>> first client, however.  the 'revocation listener' is never triggered.
>>>             I have scoured the web and not found examples.
>>>
>>>             this code assumes that you have a zookeeper server running
>>> on your local host at port 2181
>>>
>>>             ideally, I'd also like to look up from somewhere else real
>>> quick to see if the lock is in place, but perhaps
>>>             an acquire with a very short timeout (5 milliseconds) would
>>> accomplish that.
>>>
>>>            also, is  it a good idea to reap away locks after releasing
>>> them?  (to not clog up the system?)
>>>
>>> thanks
>>>
>>> -Jill
>>>
>>> ps:  also posted on stack overflow.
>>>
>>> I'll cross-post answers if I have them.
>>>  >>>>>>>>>>>>>
>>>  import java.util.Collection;
>>> import java.util.List;
>>> import java.util.concurrent.TimeUnit;
>>> import org.apache.curator.RetryPolicy;
>>> import org.apache.curator.framework.CuratorFramework;
>>> import org.apache.curator.framework.CuratorFrameworkFactory;
>>> import org.apache.curator.framework.recipes.locks.InterProcessMutex;
>>> import org.apache.curator.framework.recipes.locks.RevocationListener;
>>> import org.apache.curator.framework.recipes.locks.Revoker;
>>> import org.apache.curator.retry.ExponentialBackoffRetry;
>>>
>>> public class MultipleClientExample {
>>>
>>>
>>>     /*entry point
>>>      */
>>>     public static void main(String[] args){
>>>
>>>         RetryPolicy retryPolicy = new ExponentialBackoffRetry(1000, 3);
>>>         String zookeeperConnectionString = "127.0.0.1:2181";
>>>         CuratorFramework client =
>>> CuratorFrameworkFactory.newClient(zookeeperConnectionString, retryPolicy);
>>>         client.start();
>>>
>>>         try {
>>>             System.out.println("testing locks....");
>>>
>>>             InterProcessMutex ipMutex = new InterProcessMutex(client,
>>> "/mpx-updates/guid123/update");
>>>
>>>             boolean acquired = ipMutex.acquire(3, TimeUnit.SECONDS);
>>>             System.out.println("got the lock(update)?" + acquired);
>>>
>>>             RevocationListener<InterProcessMutex> rl = new
>>> MyRevocationListener();
>>>
>>>             ipMutex.makeRevocable(rl);
>>>
>>>             InterProcessMutex ipMutex2 = new InterProcessMutex(client,
>>> "/mpx-updates/guid123/swap");
>>>             boolean a2 = ipMutex2.acquire(3, TimeUnit.SECONDS);
>>>             System.out.println("got the lock(swap)?" + a2);
>>>
>>>             System.out.println("got the first lock in this process? " +
>>> ipMutex.isAcquiredInThisProcess());
>>>
>>>             // make a new client; see if it can get the lock!
>>>             CuratorFramework client2 =
>>> CuratorFrameworkFactory.newClient(zookeeperConnectionString, retryPolicy);
>>>             client2.start();
>>>
>>>             InterProcessMutex ipMutex1Retry = new
>>> InterProcessMutex(client2, "/mpx-updates/guid123/update");
>>>             boolean a3 = ipMutex1Retry.acquire(3, TimeUnit.SECONDS);
>>>             System.out.println("got the lock(retry/update) ?" + a3);
>>>
>>>             System.out.println("got the first lock in this process? " +
>>> ipMutex1Retry.isAcquiredInThisProcess());
>>>
>>>             Revoker.attemptRevoke(client2,
>>> "/mpx-updates/guid123/update");
>>>             a3 = ipMutex1Retry.acquire(3, TimeUnit.SECONDS);
>>>             System.out.println("AGAIN: got the lock(retry/update) ?" +
>>> a3);
>>>
>>>         } catch (Exception e) {
>>>             // TODO Auto-generated catch block
>>>             e.printStackTrace();
>>>         }
>>>
>>>     }
>>>
>>>     public class MyRevocationListener implements
>>> RevocationListener<InterProcessMutex> {
>>>
>>>         /*
>>>          * (non-Javadoc)
>>>          *
>>>          * @see
>>> org.apache.curator.framework.recipes.locks.RevocationListener#revocationRequested(java.lang.Object)
>>>          */
>>>         @Override
>>>         public void revocationRequested(InterProcessMutex lock) {
>>>
>>>             //this seems to never be called
>>>
>>>             Collection<String> participantNodes = null;
>>>
>>>             try {
>>>                 System.out.println("revocation was requested....");
>>>                 System.out.println("ick ick revocation requested....");
>>>                 participantNodes = lock.getParticipantNodes();
>>>                 lock.release();
>>>                 System.out.println("revoked lock at path: " +
>>> participantNodes);
>>>             } catch (Exception e) {
>>>                 System.out.println("problem revoking lock with path: " +
>>> participantNodes + "; it was not revoked");
>>>             }
>>>
>>>         }
>>>
>>>     }
>>> }
>>>
>>>
>>
>

Re: revocation not working

Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
PR refers to a “Pull Request”. See here: https://cwiki.apache.org/confluence/display/CURATOR/Submitting+Pull+Requests

-JZ


On October 1, 2014 at 10:07:22 AM, Singer, Jill (jill.singer@pearson.com) wrote:

I can get the path from:  getParticipantNodes();

also, I can apparently 'release' the lock by just deleting the node:
  ZKPaths.deleteChildren(client2.getZookeeperClient().getZooKeeper(), "/mpx-updates/guid123/update", false);
and then you don't even have to get the full node path.

it feels a little like a hack, but it works.

a "PR" with improvements:  this means a specific email to a specific person?

(nothing relevant in this list: http://en.wikipedia.org/wiki/PR#Computing)

-Jill












On Wed, Oct 1, 2014 at 10:53 AM, Jordan Zimmerman <jo...@jordanzimmerman.com> wrote:
* Damn - looks like getLockPath() is protected. That should be corrected. For now, create a subclass that has a new method that returns the lock path.

* the  InterProcessSemaphoreMutex does not allow revoking; so how will that help?
Damn again. Instead, you’ll need to interrupt the thread that owns the lock.

I apologize about the lack of features here. Apparently, this hasn’t been used very much. A PR with improvements would be appreciated.

-JZ

On October 1, 2014 at 9:44:13 AM, Singer, Jill (jill.singer@pearson.com) wrote:

Jordan-

    thanks for the advice!

Here are my follow-up questions:

* I can't find the 'getLockPath()"  method on the InterProcessMutex or  InterProcessSemaphoreMutex class
(I looked here: https://curator.apache.org/apidocs/index.html and couldn't find a 'getLockPath()" method anywhere (the docs are version 2.5.1-snapshot, btw)
(I am using curator version 2.5.0)

* the  InterProcessSemaphoreMutex does not allow revoking; so how will that help?

On Tue, Sep 30, 2014 at 8:46 PM, Jordan Zimmerman <jo...@jordanzimmerman.com> wrote:
There are a number of problems:

* The docs are not clear on this, but makeRevocable() must be called BEFORE the lock is acquired. Please submit a Jira/PR to fix the doc.
* In your test, Revoker.attemptRevoke was using the incorrect path. It must be the path of the lock, so: "Revoker.attemptRevoke(client2, ipMutex.getLockPath());”
* InterProcessMutex keeps track of the thread that owns the lock. So, the lock.release(); in your revoker won’t work. I suggest using InterProcessSemaphoreMutex instead.

-JZ


On September 30, 2014 at 4:19:58 PM, Singer, Jill (jill.singer@pearson.com) wrote:

short:  I want to create a lock with one client and release it with another; so I am trying to use revocation for that end.  It isn't working.  more details (and my code) are below.
any help is appreciated!



long:  have a system where one thread (with its own client) sets the first lock (update),
            then a second thread (with a client that may or may not be the same as the original client)
            will set a second lock; then do some work, then release that lock, and then release the first lock

            this code simulates two threads by having two different clients get locks.

            the second client is unable to revoke the lock from the first client, however.  the 'revocation listener' is never triggered.
            I have scoured the web and not found examples.

            this code assumes that you have a zookeeper server running on your local host at port 2181

            ideally, I'd also like to look up from somewhere else real quick to see if the lock is in place, but perhaps 
            an acquire with a very short timeout (5 milliseconds) would accomplish that.

           also, is  it a good idea to reap away locks after releasing them?  (to not clog up the system?)

thanks

-Jill

ps:  also posted on stack overflow.

I'll cross-post answers if I have them.
>>>>>>>>>>>>>
import java.util.Collection;
import java.util.List;
import java.util.concurrent.TimeUnit;
import org.apache.curator.RetryPolicy;
import org.apache.curator.framework.CuratorFramework;
import org.apache.curator.framework.CuratorFrameworkFactory;
import org.apache.curator.framework.recipes.locks.InterProcessMutex;
import org.apache.curator.framework.recipes.locks.RevocationListener;
import org.apache.curator.framework.recipes.locks.Revoker;
import org.apache.curator.retry.ExponentialBackoffRetry;

public class MultipleClientExample {


    /*entry point
     */
    public static void main(String[] args){

        RetryPolicy retryPolicy = new ExponentialBackoffRetry(1000, 3);
        String zookeeperConnectionString = "127.0.0.1:2181";
        CuratorFramework client = CuratorFrameworkFactory.newClient(zookeeperConnectionString, retryPolicy);
        client.start();

        try {
            System.out.println("testing locks....");

            InterProcessMutex ipMutex = new InterProcessMutex(client, "/mpx-updates/guid123/update");

            boolean acquired = ipMutex.acquire(3, TimeUnit.SECONDS);
            System.out.println("got the lock(update)?" + acquired);

            RevocationListener<InterProcessMutex> rl = new MyRevocationListener();

            ipMutex.makeRevocable(rl);

            InterProcessMutex ipMutex2 = new InterProcessMutex(client, "/mpx-updates/guid123/swap");
            boolean a2 = ipMutex2.acquire(3, TimeUnit.SECONDS);
            System.out.println("got the lock(swap)?" + a2);

            System.out.println("got the first lock in this process? " + ipMutex.isAcquiredInThisProcess());

            // make a new client; see if it can get the lock!
            CuratorFramework client2 = CuratorFrameworkFactory.newClient(zookeeperConnectionString, retryPolicy);
            client2.start();

            InterProcessMutex ipMutex1Retry = new InterProcessMutex(client2, "/mpx-updates/guid123/update");
            boolean a3 = ipMutex1Retry.acquire(3, TimeUnit.SECONDS);
            System.out.println("got the lock(retry/update) ?" + a3);

            System.out.println("got the first lock in this process? " + ipMutex1Retry.isAcquiredInThisProcess());

            Revoker.attemptRevoke(client2, "/mpx-updates/guid123/update");
            a3 = ipMutex1Retry.acquire(3, TimeUnit.SECONDS);
            System.out.println("AGAIN: got the lock(retry/update) ?" + a3);

        } catch (Exception e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
        }

    }

    public class MyRevocationListener implements RevocationListener<InterProcessMutex> {

        /*
         * (non-Javadoc)
         * 
         * @see org.apache.curator.framework.recipes.locks.RevocationListener#revocationRequested(java.lang.Object)
         */
        @Override
        public void revocationRequested(InterProcessMutex lock) {

            //this seems to never be called 

            Collection<String> participantNodes = null;

            try {
                System.out.println("revocation was requested....");
                System.out.println("ick ick revocation requested....");
                participantNodes = lock.getParticipantNodes();
                lock.release();
                System.out.println("revoked lock at path: " + participantNodes);
            } catch (Exception e) {
                System.out.println("problem revoking lock with path: " + participantNodes + "; it was not revoked");
            }

        }

    }
}




Re: revocation not working

Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
Some of the tests are flakey. Try building without tests.

-JZ


On October 2, 2014 at 10:59:36 AM, Singer, Jill (jill.singer@pearson.com) wrote:

I forked it, and tried to build, and got an error:
testBasic(org.apache.curator.framework.imps.TestFrameworkBackground)  Time elapsed: 10.643 sec  <<< FAILURE!
java.lang.AssertionError: Lists differ at element [0]: /one != null expected [/one] but found [null]
at org.testng.Assert.fail(Assert.java:94)
at org.testng.Assert.failNotEquals(Assert.java:494)
at org.testng.Assert.assertEquals(Assert.java:123)
at org.testng.Assert.assertEquals(Assert.java:549)
at org.testng.Assert.assertEquals(Assert.java:514)
at org.apache.curator.framework.imps.TestFrameworkBackground.testBasic(TestFrameworkBackground.java:169)


I am running zookeeper off the standard port (2181)

I looked through the websites, did google searches, and couldn't find any instructions on system setup before running the tests.

should I just compile and not worry about the tests?
(do a mvn install -DskipTests)

thanks

-Jill

On Thu, Oct 2, 2014 at 11:09 AM, Jordan Zimmerman <jo...@jordanzimmerman.com> wrote:
Yes - always work off of master.

-JZ


On October 2, 2014 at 10:07:41 AM, Singer, Jill (jill.singer@pearson.com) wrote:

if I am writing a new mutex lock class; 
which branch should I use? (master?)
(I already created a fork of the repo)

thanks

-Jill

(ps:  entered a jira ticket:
https://issues.apache.org/jira/browse/CURATOR-150)

On Wed, Oct 1, 2014 at 12:09 PM, Jordan Zimmerman <jo...@jordanzimmerman.com> wrote:
Correct


On October 1, 2014 at 10:07:22 AM, Singer, Jill (jill.singer@pearson.com) wrote:

I can get the path from:  getParticipantNodes();

also, I can apparently 'release' the lock by just deleting the node:
  ZKPaths.deleteChildren(client2.getZookeeperClient().getZooKeeper(), "/mpx-updates/guid123/update", false);
and then you don't even have to get the full node path.

it feels a little like a hack, but it works.

a "PR" with improvements:  this means a specific email to a specific person?

(nothing relevant in this list: http://en.wikipedia.org/wiki/PR#Computing)

-Jill












On Wed, Oct 1, 2014 at 10:53 AM, Jordan Zimmerman <jo...@jordanzimmerman.com> wrote:
* Damn - looks like getLockPath() is protected. That should be corrected. For now, create a subclass that has a new method that returns the lock path.

* the  InterProcessSemaphoreMutex does not allow revoking; so how will that help?
Damn again. Instead, you’ll need to interrupt the thread that owns the lock.

I apologize about the lack of features here. Apparently, this hasn’t been used very much. A PR with improvements would be appreciated.

-JZ

On October 1, 2014 at 9:44:13 AM, Singer, Jill (jill.singer@pearson.com) wrote:

Jordan-

    thanks for the advice!

Here are my follow-up questions:

* I can't find the 'getLockPath()"  method on the InterProcessMutex or  InterProcessSemaphoreMutex class
(I looked here: https://curator.apache.org/apidocs/index.html and couldn't find a 'getLockPath()" method anywhere (the docs are version 2.5.1-snapshot, btw)
(I am using curator version 2.5.0)

* the  InterProcessSemaphoreMutex does not allow revoking; so how will that help?

On Tue, Sep 30, 2014 at 8:46 PM, Jordan Zimmerman <jo...@jordanzimmerman.com> wrote:
There are a number of problems:

* The docs are not clear on this, but makeRevocable() must be called BEFORE the lock is acquired. Please submit a Jira/PR to fix the doc.
* In your test, Revoker.attemptRevoke was using the incorrect path. It must be the path of the lock, so: "Revoker.attemptRevoke(client2, ipMutex.getLockPath());”
* InterProcessMutex keeps track of the thread that owns the lock. So, the lock.release(); in your revoker won’t work. I suggest using InterProcessSemaphoreMutex instead.

-JZ


On September 30, 2014 at 4:19:58 PM, Singer, Jill (jill.singer@pearson.com) wrote:

short:  I want to create a lock with one client and release it with another; so I am trying to use revocation for that end.  It isn't working.  more details (and my code) are below.
any help is appreciated!



long:  have a system where one thread (with its own client) sets the first lock (update),
            then a second thread (with a client that may or may not be the same as the original client)
            will set a second lock; then do some work, then release that lock, and then release the first lock

            this code simulates two threads by having two different clients get locks.

            the second client is unable to revoke the lock from the first client, however.  the 'revocation listener' is never triggered.
            I have scoured the web and not found examples.

            this code assumes that you have a zookeeper server running on your local host at port 2181

            ideally, I'd also like to look up from somewhere else real quick to see if the lock is in place, but perhaps 
            an acquire with a very short timeout (5 milliseconds) would accomplish that.

           also, is  it a good idea to reap away locks after releasing them?  (to not clog up the system?)

thanks

-Jill

ps:  also posted on stack overflow.

I'll cross-post answers if I have them.
>>>>>>>>>>>>>
import java.util.Collection;
import java.util.List;
import java.util.concurrent.TimeUnit;
import org.apache.curator.RetryPolicy;
import org.apache.curator.framework.CuratorFramework;
import org.apache.curator.framework.CuratorFrameworkFactory;
import org.apache.curator.framework.recipes.locks.InterProcessMutex;
import org.apache.curator.framework.recipes.locks.RevocationListener;
import org.apache.curator.framework.recipes.locks.Revoker;
import org.apache.curator.retry.ExponentialBackoffRetry;

public class MultipleClientExample {


    /*entry point
     */
    public static void main(String[] args){

        RetryPolicy retryPolicy = new ExponentialBackoffRetry(1000, 3);
        String zookeeperConnectionString = "127.0.0.1:2181";
        CuratorFramework client = CuratorFrameworkFactory.newClient(zookeeperConnectionString, retryPolicy);
        client.start();

        try {
            System.out.println("testing locks....");

            InterProcessMutex ipMutex = new InterProcessMutex(client, "/mpx-updates/guid123/update");

            boolean acquired = ipMutex.acquire(3, TimeUnit.SECONDS);
            System.out.println("got the lock(update)?" + acquired);

            RevocationListener<InterProcessMutex> rl = new MyRevocationListener();

            ipMutex.makeRevocable(rl);

            InterProcessMutex ipMutex2 = new InterProcessMutex(client, "/mpx-updates/guid123/swap");
            boolean a2 = ipMutex2.acquire(3, TimeUnit.SECONDS);
            System.out.println("got the lock(swap)?" + a2);

            System.out.println("got the first lock in this process? " + ipMutex.isAcquiredInThisProcess());

            // make a new client; see if it can get the lock!
            CuratorFramework client2 = CuratorFrameworkFactory.newClient(zookeeperConnectionString, retryPolicy);
            client2.start();

            InterProcessMutex ipMutex1Retry = new InterProcessMutex(client2, "/mpx-updates/guid123/update");
            boolean a3 = ipMutex1Retry.acquire(3, TimeUnit.SECONDS);
            System.out.println("got the lock(retry/update) ?" + a3);

            System.out.println("got the first lock in this process? " + ipMutex1Retry.isAcquiredInThisProcess());

            Revoker.attemptRevoke(client2, "/mpx-updates/guid123/update");
            a3 = ipMutex1Retry.acquire(3, TimeUnit.SECONDS);
            System.out.println("AGAIN: got the lock(retry/update) ?" + a3);

        } catch (Exception e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
        }

    }

    public class MyRevocationListener implements RevocationListener<InterProcessMutex> {

        /*
         * (non-Javadoc)
         * 
         * @see org.apache.curator.framework.recipes.locks.RevocationListener#revocationRequested(java.lang.Object)
         */
        @Override
        public void revocationRequested(InterProcessMutex lock) {

            //this seems to never be called 

            Collection<String> participantNodes = null;

            try {
                System.out.println("revocation was requested....");
                System.out.println("ick ick revocation requested....");
                participantNodes = lock.getParticipantNodes();
                lock.release();
                System.out.println("revoked lock at path: " + participantNodes);
            } catch (Exception e) {
                System.out.println("problem revoking lock with path: " + participantNodes + "; it was not revoked");
            }

        }

    }
}






Re: revocation not working

Posted by "Singer, Jill" <ji...@pearson.com>.
I forked it, and tried to build, and got an error:
testBasic(org.apache.curator.framework.imps.TestFrameworkBackground)  Time
elapsed: 10.643 sec  <<< FAILURE!
java.lang.AssertionError: Lists differ at element [0]: /one != null
expected [/one] but found [null]
at org.testng.Assert.fail(Assert.java:94)
at org.testng.Assert.failNotEquals(Assert.java:494)
at org.testng.Assert.assertEquals(Assert.java:123)
at org.testng.Assert.assertEquals(Assert.java:549)
at org.testng.Assert.assertEquals(Assert.java:514)
at
org.apache.curator.framework.imps.TestFrameworkBackground.testBasic(TestFrameworkBackground.java:169)


I am running zookeeper off the standard port (2181)

I looked through the websites, did google searches, and couldn't find any
instructions on system setup before running the tests.

should I just compile and not worry about the tests?
(do a mvn install -DskipTests)

thanks

-Jill

On Thu, Oct 2, 2014 at 11:09 AM, Jordan Zimmerman <
jordan@jordanzimmerman.com> wrote:

> Yes - always work off of master.
>
> -JZ
>
>
> On October 2, 2014 at 10:07:41 AM, Singer, Jill (jill.singer@pearson.com)
> wrote:
>
> if I am writing a new mutex lock class;
> which branch should I use? (master?)
> (I already created a fork of the repo)
>
> thanks
>
> -Jill
>
> (ps:  entered a jira ticket:
> https://issues.apache.org/jira/browse/CURATOR-150)
>
> On Wed, Oct 1, 2014 at 12:09 PM, Jordan Zimmerman <
> jordan@jordanzimmerman.com> wrote:
>
>>  Correct
>>
>>
>> On October 1, 2014 at 10:07:22 AM, Singer, Jill (jill.singer@pearson.com)
>> wrote:
>>
>>  I can get the path from:  getParticipantNodes();
>>
>> also, I can apparently 'release' the lock by just deleting the node:
>>   ZKPaths.deleteChildren(client2.getZookeeperClient().getZooKeeper(),
>> "/mpx-updates/guid123/update", false);
>>
>> and then you don't even have to get the full node path.
>>
>> it feels a little like a hack, but it works.
>>
>> a "PR" with improvements:  this means a specific email to a specific
>> person?
>>
>> (nothing relevant in this list: http://en.wikipedia.org/wiki/PR#Computing
>> )
>>
>> -Jill
>>
>>
>>
>>
>>
>>
>>
>> On Wed, Oct 1, 2014 at 10:53 AM, Jordan Zimmerman <
>> jordan@jordanzimmerman.com> wrote:
>>
>>>  * Damn - looks like getLockPath() is protected. That should be
>>> corrected. For now, create a subclass that has a new method that returns
>>> the lock path.
>>>
>>>  * the  InterProcessSemaphoreMutex does not allow revoking; so how will
>>> that help?
>>>
>>>  Damn again. Instead, you’ll need to interrupt the thread that owns the
>>> lock.
>>>
>>> I apologize about the lack of features here. Apparently, this hasn’t
>>> been used very much. A PR with improvements would be appreciated.
>>>
>>> -JZ
>>>
>>> On October 1, 2014 at 9:44:13 AM, Singer, Jill (jill.singer@pearson.com)
>>> wrote:
>>>
>>>  Jordan-
>>>
>>>     thanks for the advice!
>>>
>>> Here are my follow-up questions:
>>>
>>> * I can't find the 'getLockPath()"  method on the InterProcessMutex or  InterProcessSemaphoreMutex
>>> class
>>>  (I looked here: https://curator.apache.org/apidocs/index.html and
>>> couldn't find a 'getLockPath()" method anywhere (the docs are version
>>> 2.5.1-snapshot, btw)
>>> (I am using curator version 2.5.0)
>>>
>>>  * the  InterProcessSemaphoreMutex does not allow revoking; so how will
>>> that help?
>>>
>>> On Tue, Sep 30, 2014 at 8:46 PM, Jordan Zimmerman <
>>> jordan@jordanzimmerman.com> wrote:
>>>
>>>>  There are a number of problems:
>>>>
>>>>  * The docs are not clear on this, but makeRevocable() must be called
>>>> BEFORE the lock is acquired. Please submit a Jira/PR to fix the doc.
>>>>  * In your test, Revoker.attemptRevoke was using the incorrect path. It
>>>> must be the path of the lock, so: "Revoker.attemptRevoke(client2,
>>>> ipMutex.getLockPath());”
>>>>  * InterProcessMutex keeps track of the thread that owns the lock. So,
>>>> the lock.release(); in your revoker won’t work. I suggest
>>>> using InterProcessSemaphoreMutex instead.
>>>>
>>>>  -JZ
>>>>
>>>>
>>>> On September 30, 2014 at 4:19:58 PM, Singer, Jill (
>>>> jill.singer@pearson.com) wrote:
>>>>
>>>>   short:  I want to create a lock with one client and release it with
>>>> another; so I am trying to use revocation for that end.  It isn't working.
>>>>  more details (and my code) are below.
>>>> any help is appreciated!
>>>>
>>>>
>>>>
>>>> long:  have a system where one thread (with its own client) sets the
>>>> first lock (update),
>>>>             then a second thread (with a client that may or may not be
>>>> the same as the original client)
>>>>             will set a second lock; then do some work, then release
>>>> that lock, and then release the first lock
>>>>
>>>>             this code simulates two threads by having two different
>>>> clients get locks.
>>>>
>>>>             the second client is unable to revoke the lock from the
>>>> first client, however.  the 'revocation listener' is never triggered.
>>>>             I have scoured the web and not found examples.
>>>>
>>>>             this code assumes that you have a zookeeper server running
>>>> on your local host at port 2181
>>>>
>>>>             ideally, I'd also like to look up from somewhere else real
>>>> quick to see if the lock is in place, but perhaps
>>>>             an acquire with a very short timeout (5 milliseconds) would
>>>> accomplish that.
>>>>
>>>>            also, is  it a good idea to reap away locks after releasing
>>>> them?  (to not clog up the system?)
>>>>
>>>> thanks
>>>>
>>>> -Jill
>>>>
>>>> ps:  also posted on stack overflow.
>>>>
>>>> I'll cross-post answers if I have them.
>>>>  >>>>>>>>>>>>>
>>>>  import java.util.Collection;
>>>> import java.util.List;
>>>> import java.util.concurrent.TimeUnit;
>>>> import org.apache.curator.RetryPolicy;
>>>> import org.apache.curator.framework.CuratorFramework;
>>>> import org.apache.curator.framework.CuratorFrameworkFactory;
>>>> import org.apache.curator.framework.recipes.locks.InterProcessMutex;
>>>> import org.apache.curator.framework.recipes.locks.RevocationListener;
>>>> import org.apache.curator.framework.recipes.locks.Revoker;
>>>> import org.apache.curator.retry.ExponentialBackoffRetry;
>>>>
>>>> public class MultipleClientExample {
>>>>
>>>>
>>>>     /*entry point
>>>>      */
>>>>     public static void main(String[] args){
>>>>
>>>>         RetryPolicy retryPolicy = new ExponentialBackoffRetry(1000, 3);
>>>>         String zookeeperConnectionString = "127.0.0.1:2181";
>>>>         CuratorFramework client =
>>>> CuratorFrameworkFactory.newClient(zookeeperConnectionString, retryPolicy);
>>>>         client.start();
>>>>
>>>>         try {
>>>>             System.out.println("testing locks....");
>>>>
>>>>             InterProcessMutex ipMutex = new InterProcessMutex(client,
>>>> "/mpx-updates/guid123/update");
>>>>
>>>>             boolean acquired = ipMutex.acquire(3, TimeUnit.SECONDS);
>>>>             System.out.println("got the lock(update)?" + acquired);
>>>>
>>>>             RevocationListener<InterProcessMutex> rl = new
>>>> MyRevocationListener();
>>>>
>>>>             ipMutex.makeRevocable(rl);
>>>>
>>>>             InterProcessMutex ipMutex2 = new InterProcessMutex(client,
>>>> "/mpx-updates/guid123/swap");
>>>>             boolean a2 = ipMutex2.acquire(3, TimeUnit.SECONDS);
>>>>             System.out.println("got the lock(swap)?" + a2);
>>>>
>>>>             System.out.println("got the first lock in this process? " +
>>>> ipMutex.isAcquiredInThisProcess());
>>>>
>>>>             // make a new client; see if it can get the lock!
>>>>             CuratorFramework client2 =
>>>> CuratorFrameworkFactory.newClient(zookeeperConnectionString, retryPolicy);
>>>>             client2.start();
>>>>
>>>>             InterProcessMutex ipMutex1Retry = new
>>>> InterProcessMutex(client2, "/mpx-updates/guid123/update");
>>>>             boolean a3 = ipMutex1Retry.acquire(3, TimeUnit.SECONDS);
>>>>             System.out.println("got the lock(retry/update) ?" + a3);
>>>>
>>>>             System.out.println("got the first lock in this process? " +
>>>> ipMutex1Retry.isAcquiredInThisProcess());
>>>>
>>>>             Revoker.attemptRevoke(client2,
>>>> "/mpx-updates/guid123/update");
>>>>             a3 = ipMutex1Retry.acquire(3, TimeUnit.SECONDS);
>>>>             System.out.println("AGAIN: got the lock(retry/update) ?" +
>>>> a3);
>>>>
>>>>         } catch (Exception e) {
>>>>             // TODO Auto-generated catch block
>>>>             e.printStackTrace();
>>>>         }
>>>>
>>>>     }
>>>>
>>>>     public class MyRevocationListener implements
>>>> RevocationListener<InterProcessMutex> {
>>>>
>>>>         /*
>>>>          * (non-Javadoc)
>>>>          *
>>>>          * @see
>>>> org.apache.curator.framework.recipes.locks.RevocationListener#revocationRequested(java.lang.Object)
>>>>          */
>>>>         @Override
>>>>         public void revocationRequested(InterProcessMutex lock) {
>>>>
>>>>             //this seems to never be called
>>>>
>>>>             Collection<String> participantNodes = null;
>>>>
>>>>             try {
>>>>                 System.out.println("revocation was requested....");
>>>>                 System.out.println("ick ick revocation requested....");
>>>>                 participantNodes = lock.getParticipantNodes();
>>>>                 lock.release();
>>>>                 System.out.println("revoked lock at path: " +
>>>> participantNodes);
>>>>             } catch (Exception e) {
>>>>                 System.out.println("problem revoking lock with path: "
>>>> + participantNodes + "; it was not revoked");
>>>>             }
>>>>
>>>>         }
>>>>
>>>>     }
>>>> }
>>>>
>>>>
>>>
>>
>

Re: revocation not working

Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
Yes - always work off of master.

-JZ


On October 2, 2014 at 10:07:41 AM, Singer, Jill (jill.singer@pearson.com) wrote:

if I am writing a new mutex lock class; 
which branch should I use? (master?)
(I already created a fork of the repo)

thanks

-Jill

(ps:  entered a jira ticket:
https://issues.apache.org/jira/browse/CURATOR-150)

On Wed, Oct 1, 2014 at 12:09 PM, Jordan Zimmerman <jo...@jordanzimmerman.com> wrote:
Correct


On October 1, 2014 at 10:07:22 AM, Singer, Jill (jill.singer@pearson.com) wrote:

I can get the path from:  getParticipantNodes();

also, I can apparently 'release' the lock by just deleting the node:
  ZKPaths.deleteChildren(client2.getZookeeperClient().getZooKeeper(), "/mpx-updates/guid123/update", false);
and then you don't even have to get the full node path.

it feels a little like a hack, but it works.

a "PR" with improvements:  this means a specific email to a specific person?

(nothing relevant in this list: http://en.wikipedia.org/wiki/PR#Computing)

-Jill












On Wed, Oct 1, 2014 at 10:53 AM, Jordan Zimmerman <jo...@jordanzimmerman.com> wrote:
* Damn - looks like getLockPath() is protected. That should be corrected. For now, create a subclass that has a new method that returns the lock path.

* the  InterProcessSemaphoreMutex does not allow revoking; so how will that help?
Damn again. Instead, you’ll need to interrupt the thread that owns the lock.

I apologize about the lack of features here. Apparently, this hasn’t been used very much. A PR with improvements would be appreciated.

-JZ

On October 1, 2014 at 9:44:13 AM, Singer, Jill (jill.singer@pearson.com) wrote:

Jordan-

    thanks for the advice!

Here are my follow-up questions:

* I can't find the 'getLockPath()"  method on the InterProcessMutex or  InterProcessSemaphoreMutex class
(I looked here: https://curator.apache.org/apidocs/index.html and couldn't find a 'getLockPath()" method anywhere (the docs are version 2.5.1-snapshot, btw)
(I am using curator version 2.5.0)

* the  InterProcessSemaphoreMutex does not allow revoking; so how will that help?

On Tue, Sep 30, 2014 at 8:46 PM, Jordan Zimmerman <jo...@jordanzimmerman.com> wrote:
There are a number of problems:

* The docs are not clear on this, but makeRevocable() must be called BEFORE the lock is acquired. Please submit a Jira/PR to fix the doc.
* In your test, Revoker.attemptRevoke was using the incorrect path. It must be the path of the lock, so: "Revoker.attemptRevoke(client2, ipMutex.getLockPath());”
* InterProcessMutex keeps track of the thread that owns the lock. So, the lock.release(); in your revoker won’t work. I suggest using InterProcessSemaphoreMutex instead.

-JZ


On September 30, 2014 at 4:19:58 PM, Singer, Jill (jill.singer@pearson.com) wrote:

short:  I want to create a lock with one client and release it with another; so I am trying to use revocation for that end.  It isn't working.  more details (and my code) are below.
any help is appreciated!



long:  have a system where one thread (with its own client) sets the first lock (update),
            then a second thread (with a client that may or may not be the same as the original client)
            will set a second lock; then do some work, then release that lock, and then release the first lock

            this code simulates two threads by having two different clients get locks.

            the second client is unable to revoke the lock from the first client, however.  the 'revocation listener' is never triggered.
            I have scoured the web and not found examples.

            this code assumes that you have a zookeeper server running on your local host at port 2181

            ideally, I'd also like to look up from somewhere else real quick to see if the lock is in place, but perhaps 
            an acquire with a very short timeout (5 milliseconds) would accomplish that.

           also, is  it a good idea to reap away locks after releasing them?  (to not clog up the system?)

thanks

-Jill

ps:  also posted on stack overflow.

I'll cross-post answers if I have them.
>>>>>>>>>>>>>
import java.util.Collection;
import java.util.List;
import java.util.concurrent.TimeUnit;
import org.apache.curator.RetryPolicy;
import org.apache.curator.framework.CuratorFramework;
import org.apache.curator.framework.CuratorFrameworkFactory;
import org.apache.curator.framework.recipes.locks.InterProcessMutex;
import org.apache.curator.framework.recipes.locks.RevocationListener;
import org.apache.curator.framework.recipes.locks.Revoker;
import org.apache.curator.retry.ExponentialBackoffRetry;

public class MultipleClientExample {


    /*entry point
     */
    public static void main(String[] args){

        RetryPolicy retryPolicy = new ExponentialBackoffRetry(1000, 3);
        String zookeeperConnectionString = "127.0.0.1:2181";
        CuratorFramework client = CuratorFrameworkFactory.newClient(zookeeperConnectionString, retryPolicy);
        client.start();

        try {
            System.out.println("testing locks....");

            InterProcessMutex ipMutex = new InterProcessMutex(client, "/mpx-updates/guid123/update");

            boolean acquired = ipMutex.acquire(3, TimeUnit.SECONDS);
            System.out.println("got the lock(update)?" + acquired);

            RevocationListener<InterProcessMutex> rl = new MyRevocationListener();

            ipMutex.makeRevocable(rl);

            InterProcessMutex ipMutex2 = new InterProcessMutex(client, "/mpx-updates/guid123/swap");
            boolean a2 = ipMutex2.acquire(3, TimeUnit.SECONDS);
            System.out.println("got the lock(swap)?" + a2);

            System.out.println("got the first lock in this process? " + ipMutex.isAcquiredInThisProcess());

            // make a new client; see if it can get the lock!
            CuratorFramework client2 = CuratorFrameworkFactory.newClient(zookeeperConnectionString, retryPolicy);
            client2.start();

            InterProcessMutex ipMutex1Retry = new InterProcessMutex(client2, "/mpx-updates/guid123/update");
            boolean a3 = ipMutex1Retry.acquire(3, TimeUnit.SECONDS);
            System.out.println("got the lock(retry/update) ?" + a3);

            System.out.println("got the first lock in this process? " + ipMutex1Retry.isAcquiredInThisProcess());

            Revoker.attemptRevoke(client2, "/mpx-updates/guid123/update");
            a3 = ipMutex1Retry.acquire(3, TimeUnit.SECONDS);
            System.out.println("AGAIN: got the lock(retry/update) ?" + a3);

        } catch (Exception e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
        }

    }

    public class MyRevocationListener implements RevocationListener<InterProcessMutex> {

        /*
         * (non-Javadoc)
         * 
         * @see org.apache.curator.framework.recipes.locks.RevocationListener#revocationRequested(java.lang.Object)
         */
        @Override
        public void revocationRequested(InterProcessMutex lock) {

            //this seems to never be called 

            Collection<String> participantNodes = null;

            try {
                System.out.println("revocation was requested....");
                System.out.println("ick ick revocation requested....");
                participantNodes = lock.getParticipantNodes();
                lock.release();
                System.out.println("revoked lock at path: " + participantNodes);
            } catch (Exception e) {
                System.out.println("problem revoking lock with path: " + participantNodes + "; it was not revoked");
            }

        }

    }
}





Re: revocation not working

Posted by "Singer, Jill" <ji...@pearson.com>.
if I am writing a new mutex lock class;
which branch should I use? (master?)
(I already created a fork of the repo)

thanks

-Jill

(ps:  entered a jira ticket:
https://issues.apache.org/jira/browse/CURATOR-150)

On Wed, Oct 1, 2014 at 12:09 PM, Jordan Zimmerman <
jordan@jordanzimmerman.com> wrote:

> Correct
>
>
> On October 1, 2014 at 10:07:22 AM, Singer, Jill (jill.singer@pearson.com)
> wrote:
>
> I can get the path from:  getParticipantNodes();
>
> also, I can apparently 'release' the lock by just deleting the node:
>   ZKPaths.deleteChildren(client2.getZookeeperClient().getZooKeeper(),
> "/mpx-updates/guid123/update", false);
>
> and then you don't even have to get the full node path.
>
> it feels a little like a hack, but it works.
>
> a "PR" with improvements:  this means a specific email to a specific
> person?
>
> (nothing relevant in this list: http://en.wikipedia.org/wiki/PR#Computing)
>
> -Jill
>
>
>
>
>
>
>
> On Wed, Oct 1, 2014 at 10:53 AM, Jordan Zimmerman <
> jordan@jordanzimmerman.com> wrote:
>
>>  * Damn - looks like getLockPath() is protected. That should be
>> corrected. For now, create a subclass that has a new method that returns
>> the lock path.
>>
>>  * the  InterProcessSemaphoreMutex does not allow revoking; so how will
>> that help?
>>
>>  Damn again. Instead, you’ll need to interrupt the thread that owns the
>> lock.
>>
>> I apologize about the lack of features here. Apparently, this hasn’t
>> been used very much. A PR with improvements would be appreciated.
>>
>> -JZ
>>
>> On October 1, 2014 at 9:44:13 AM, Singer, Jill (jill.singer@pearson.com)
>> wrote:
>>
>>  Jordan-
>>
>>     thanks for the advice!
>>
>> Here are my follow-up questions:
>>
>> * I can't find the 'getLockPath()"  method on the InterProcessMutex or  InterProcessSemaphoreMutex
>> class
>>  (I looked here: https://curator.apache.org/apidocs/index.html and
>> couldn't find a 'getLockPath()" method anywhere (the docs are version
>> 2.5.1-snapshot, btw)
>> (I am using curator version 2.5.0)
>>
>>  * the  InterProcessSemaphoreMutex does not allow revoking; so how will
>> that help?
>>
>> On Tue, Sep 30, 2014 at 8:46 PM, Jordan Zimmerman <
>> jordan@jordanzimmerman.com> wrote:
>>
>>>  There are a number of problems:
>>>
>>>  * The docs are not clear on this, but makeRevocable() must be called
>>> BEFORE the lock is acquired. Please submit a Jira/PR to fix the doc.
>>>  * In your test, Revoker.attemptRevoke was using the incorrect path. It
>>> must be the path of the lock, so: "Revoker.attemptRevoke(client2,
>>> ipMutex.getLockPath());”
>>>  * InterProcessMutex keeps track of the thread that owns the lock. So,
>>> the lock.release(); in your revoker won’t work. I suggest
>>> using InterProcessSemaphoreMutex instead.
>>>
>>>  -JZ
>>>
>>>
>>> On September 30, 2014 at 4:19:58 PM, Singer, Jill (
>>> jill.singer@pearson.com) wrote:
>>>
>>>   short:  I want to create a lock with one client and release it with
>>> another; so I am trying to use revocation for that end.  It isn't working.
>>>  more details (and my code) are below.
>>> any help is appreciated!
>>>
>>>
>>>
>>> long:  have a system where one thread (with its own client) sets the
>>> first lock (update),
>>>             then a second thread (with a client that may or may not be
>>> the same as the original client)
>>>             will set a second lock; then do some work, then release that
>>> lock, and then release the first lock
>>>
>>>             this code simulates two threads by having two different
>>> clients get locks.
>>>
>>>             the second client is unable to revoke the lock from the
>>> first client, however.  the 'revocation listener' is never triggered.
>>>             I have scoured the web and not found examples.
>>>
>>>             this code assumes that you have a zookeeper server running
>>> on your local host at port 2181
>>>
>>>             ideally, I'd also like to look up from somewhere else real
>>> quick to see if the lock is in place, but perhaps
>>>             an acquire with a very short timeout (5 milliseconds) would
>>> accomplish that.
>>>
>>>            also, is  it a good idea to reap away locks after releasing
>>> them?  (to not clog up the system?)
>>>
>>> thanks
>>>
>>> -Jill
>>>
>>> ps:  also posted on stack overflow.
>>>
>>> I'll cross-post answers if I have them.
>>>  >>>>>>>>>>>>>
>>>  import java.util.Collection;
>>> import java.util.List;
>>> import java.util.concurrent.TimeUnit;
>>> import org.apache.curator.RetryPolicy;
>>> import org.apache.curator.framework.CuratorFramework;
>>> import org.apache.curator.framework.CuratorFrameworkFactory;
>>> import org.apache.curator.framework.recipes.locks.InterProcessMutex;
>>> import org.apache.curator.framework.recipes.locks.RevocationListener;
>>> import org.apache.curator.framework.recipes.locks.Revoker;
>>> import org.apache.curator.retry.ExponentialBackoffRetry;
>>>
>>> public class MultipleClientExample {
>>>
>>>
>>>     /*entry point
>>>      */
>>>     public static void main(String[] args){
>>>
>>>         RetryPolicy retryPolicy = new ExponentialBackoffRetry(1000, 3);
>>>         String zookeeperConnectionString = "127.0.0.1:2181";
>>>         CuratorFramework client =
>>> CuratorFrameworkFactory.newClient(zookeeperConnectionString, retryPolicy);
>>>         client.start();
>>>
>>>         try {
>>>             System.out.println("testing locks....");
>>>
>>>             InterProcessMutex ipMutex = new InterProcessMutex(client,
>>> "/mpx-updates/guid123/update");
>>>
>>>             boolean acquired = ipMutex.acquire(3, TimeUnit.SECONDS);
>>>             System.out.println("got the lock(update)?" + acquired);
>>>
>>>             RevocationListener<InterProcessMutex> rl = new
>>> MyRevocationListener();
>>>
>>>             ipMutex.makeRevocable(rl);
>>>
>>>             InterProcessMutex ipMutex2 = new InterProcessMutex(client,
>>> "/mpx-updates/guid123/swap");
>>>             boolean a2 = ipMutex2.acquire(3, TimeUnit.SECONDS);
>>>             System.out.println("got the lock(swap)?" + a2);
>>>
>>>             System.out.println("got the first lock in this process? " +
>>> ipMutex.isAcquiredInThisProcess());
>>>
>>>             // make a new client; see if it can get the lock!
>>>             CuratorFramework client2 =
>>> CuratorFrameworkFactory.newClient(zookeeperConnectionString, retryPolicy);
>>>             client2.start();
>>>
>>>             InterProcessMutex ipMutex1Retry = new
>>> InterProcessMutex(client2, "/mpx-updates/guid123/update");
>>>             boolean a3 = ipMutex1Retry.acquire(3, TimeUnit.SECONDS);
>>>             System.out.println("got the lock(retry/update) ?" + a3);
>>>
>>>             System.out.println("got the first lock in this process? " +
>>> ipMutex1Retry.isAcquiredInThisProcess());
>>>
>>>             Revoker.attemptRevoke(client2,
>>> "/mpx-updates/guid123/update");
>>>             a3 = ipMutex1Retry.acquire(3, TimeUnit.SECONDS);
>>>             System.out.println("AGAIN: got the lock(retry/update) ?" +
>>> a3);
>>>
>>>         } catch (Exception e) {
>>>             // TODO Auto-generated catch block
>>>             e.printStackTrace();
>>>         }
>>>
>>>     }
>>>
>>>     public class MyRevocationListener implements
>>> RevocationListener<InterProcessMutex> {
>>>
>>>         /*
>>>          * (non-Javadoc)
>>>          *
>>>          * @see
>>> org.apache.curator.framework.recipes.locks.RevocationListener#revocationRequested(java.lang.Object)
>>>          */
>>>         @Override
>>>         public void revocationRequested(InterProcessMutex lock) {
>>>
>>>             //this seems to never be called
>>>
>>>             Collection<String> participantNodes = null;
>>>
>>>             try {
>>>                 System.out.println("revocation was requested....");
>>>                 System.out.println("ick ick revocation requested....");
>>>                 participantNodes = lock.getParticipantNodes();
>>>                 lock.release();
>>>                 System.out.println("revoked lock at path: " +
>>> participantNodes);
>>>             } catch (Exception e) {
>>>                 System.out.println("problem revoking lock with path: " +
>>> participantNodes + "; it was not revoked");
>>>             }
>>>
>>>         }
>>>
>>>     }
>>> }
>>>
>>>
>>
>

Re: revocation not working

Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
Correct


On October 1, 2014 at 10:07:22 AM, Singer, Jill (jill.singer@pearson.com) wrote:

I can get the path from:  getParticipantNodes();

also, I can apparently 'release' the lock by just deleting the node:
  ZKPaths.deleteChildren(client2.getZookeeperClient().getZooKeeper(), "/mpx-updates/guid123/update", false);
and then you don't even have to get the full node path.

it feels a little like a hack, but it works.

a "PR" with improvements:  this means a specific email to a specific person?

(nothing relevant in this list: http://en.wikipedia.org/wiki/PR#Computing)

-Jill












On Wed, Oct 1, 2014 at 10:53 AM, Jordan Zimmerman <jo...@jordanzimmerman.com> wrote:
* Damn - looks like getLockPath() is protected. That should be corrected. For now, create a subclass that has a new method that returns the lock path.

* the  InterProcessSemaphoreMutex does not allow revoking; so how will that help?
Damn again. Instead, you’ll need to interrupt the thread that owns the lock.

I apologize about the lack of features here. Apparently, this hasn’t been used very much. A PR with improvements would be appreciated.

-JZ

On October 1, 2014 at 9:44:13 AM, Singer, Jill (jill.singer@pearson.com) wrote:

Jordan-

    thanks for the advice!

Here are my follow-up questions:

* I can't find the 'getLockPath()"  method on the InterProcessMutex or  InterProcessSemaphoreMutex class
(I looked here: https://curator.apache.org/apidocs/index.html and couldn't find a 'getLockPath()" method anywhere (the docs are version 2.5.1-snapshot, btw)
(I am using curator version 2.5.0)

* the  InterProcessSemaphoreMutex does not allow revoking; so how will that help?

On Tue, Sep 30, 2014 at 8:46 PM, Jordan Zimmerman <jo...@jordanzimmerman.com> wrote:
There are a number of problems:

* The docs are not clear on this, but makeRevocable() must be called BEFORE the lock is acquired. Please submit a Jira/PR to fix the doc.
* In your test, Revoker.attemptRevoke was using the incorrect path. It must be the path of the lock, so: "Revoker.attemptRevoke(client2, ipMutex.getLockPath());”
* InterProcessMutex keeps track of the thread that owns the lock. So, the lock.release(); in your revoker won’t work. I suggest using InterProcessSemaphoreMutex instead.

-JZ


On September 30, 2014 at 4:19:58 PM, Singer, Jill (jill.singer@pearson.com) wrote:

short:  I want to create a lock with one client and release it with another; so I am trying to use revocation for that end.  It isn't working.  more details (and my code) are below.
any help is appreciated!



long:  have a system where one thread (with its own client) sets the first lock (update),
            then a second thread (with a client that may or may not be the same as the original client)
            will set a second lock; then do some work, then release that lock, and then release the first lock

            this code simulates two threads by having two different clients get locks.

            the second client is unable to revoke the lock from the first client, however.  the 'revocation listener' is never triggered.
            I have scoured the web and not found examples.

            this code assumes that you have a zookeeper server running on your local host at port 2181

            ideally, I'd also like to look up from somewhere else real quick to see if the lock is in place, but perhaps 
            an acquire with a very short timeout (5 milliseconds) would accomplish that.

           also, is  it a good idea to reap away locks after releasing them?  (to not clog up the system?)

thanks

-Jill

ps:  also posted on stack overflow.

I'll cross-post answers if I have them.
>>>>>>>>>>>>>
import java.util.Collection;
import java.util.List;
import java.util.concurrent.TimeUnit;
import org.apache.curator.RetryPolicy;
import org.apache.curator.framework.CuratorFramework;
import org.apache.curator.framework.CuratorFrameworkFactory;
import org.apache.curator.framework.recipes.locks.InterProcessMutex;
import org.apache.curator.framework.recipes.locks.RevocationListener;
import org.apache.curator.framework.recipes.locks.Revoker;
import org.apache.curator.retry.ExponentialBackoffRetry;

public class MultipleClientExample {


    /*entry point
     */
    public static void main(String[] args){

        RetryPolicy retryPolicy = new ExponentialBackoffRetry(1000, 3);
        String zookeeperConnectionString = "127.0.0.1:2181";
        CuratorFramework client = CuratorFrameworkFactory.newClient(zookeeperConnectionString, retryPolicy);
        client.start();

        try {
            System.out.println("testing locks....");

            InterProcessMutex ipMutex = new InterProcessMutex(client, "/mpx-updates/guid123/update");

            boolean acquired = ipMutex.acquire(3, TimeUnit.SECONDS);
            System.out.println("got the lock(update)?" + acquired);

            RevocationListener<InterProcessMutex> rl = new MyRevocationListener();

            ipMutex.makeRevocable(rl);

            InterProcessMutex ipMutex2 = new InterProcessMutex(client, "/mpx-updates/guid123/swap");
            boolean a2 = ipMutex2.acquire(3, TimeUnit.SECONDS);
            System.out.println("got the lock(swap)?" + a2);

            System.out.println("got the first lock in this process? " + ipMutex.isAcquiredInThisProcess());

            // make a new client; see if it can get the lock!
            CuratorFramework client2 = CuratorFrameworkFactory.newClient(zookeeperConnectionString, retryPolicy);
            client2.start();

            InterProcessMutex ipMutex1Retry = new InterProcessMutex(client2, "/mpx-updates/guid123/update");
            boolean a3 = ipMutex1Retry.acquire(3, TimeUnit.SECONDS);
            System.out.println("got the lock(retry/update) ?" + a3);

            System.out.println("got the first lock in this process? " + ipMutex1Retry.isAcquiredInThisProcess());

            Revoker.attemptRevoke(client2, "/mpx-updates/guid123/update");
            a3 = ipMutex1Retry.acquire(3, TimeUnit.SECONDS);
            System.out.println("AGAIN: got the lock(retry/update) ?" + a3);

        } catch (Exception e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
        }

    }

    public class MyRevocationListener implements RevocationListener<InterProcessMutex> {

        /*
         * (non-Javadoc)
         * 
         * @see org.apache.curator.framework.recipes.locks.RevocationListener#revocationRequested(java.lang.Object)
         */
        @Override
        public void revocationRequested(InterProcessMutex lock) {

            //this seems to never be called 

            Collection<String> participantNodes = null;

            try {
                System.out.println("revocation was requested....");
                System.out.println("ick ick revocation requested....");
                participantNodes = lock.getParticipantNodes();
                lock.release();
                System.out.println("revoked lock at path: " + participantNodes);
            } catch (Exception e) {
                System.out.println("problem revoking lock with path: " + participantNodes + "; it was not revoked");
            }

        }

    }
}




Re: revocation not working

Posted by "Singer, Jill" <ji...@pearson.com>.
I can get the path from:  getParticipantNodes();

also, I can apparently 'release' the lock by just deleting the node:
  ZKPaths.deleteChildren(client2.getZookeeperClient().getZooKeeper(),
"/mpx-updates/guid123/update", false);

and then you don't even have to get the full node path.

it feels a little like a hack, but it works.

a "PR" with improvements:  this means a specific email to a specific person?

(nothing relevant in this list: http://en.wikipedia.org/wiki/PR#Computing)

-Jill







On Wed, Oct 1, 2014 at 10:53 AM, Jordan Zimmerman <
jordan@jordanzimmerman.com> wrote:

> * Damn - looks like getLockPath() is protected. That should be corrected.
> For now, create a subclass that has a new method that returns the lock path.
>
> * the  InterProcessSemaphoreMutex does not allow revoking; so how will
> that help?
>
> Damn again. Instead, you’ll need to interrupt the thread that owns the
> lock.
>
> I apologize about the lack of features here. Apparently, this hasn’t been
> used very much. A PR with improvements would be appreciated.
>
> -JZ
>
> On October 1, 2014 at 9:44:13 AM, Singer, Jill (jill.singer@pearson.com)
> wrote:
>
> Jordan-
>
>     thanks for the advice!
>
> Here are my follow-up questions:
>
> * I can't find the 'getLockPath()"  method on the InterProcessMutex or  InterProcessSemaphoreMutex
> class
>  (I looked here: https://curator.apache.org/apidocs/index.html and
> couldn't find a 'getLockPath()" method anywhere (the docs are version
> 2.5.1-snapshot, btw)
> (I am using curator version 2.5.0)
>
>  * the  InterProcessSemaphoreMutex does not allow revoking; so how will
> that help?
>
> On Tue, Sep 30, 2014 at 8:46 PM, Jordan Zimmerman <
> jordan@jordanzimmerman.com> wrote:
>
>>  There are a number of problems:
>>
>>  * The docs are not clear on this, but makeRevocable() must be called
>> BEFORE the lock is acquired. Please submit a Jira/PR to fix the doc.
>>  * In your test, Revoker.attemptRevoke was using the incorrect path. It
>> must be the path of the lock, so: "Revoker.attemptRevoke(client2,
>> ipMutex.getLockPath());”
>>  * InterProcessMutex keeps track of the thread that owns the lock. So,
>> the lock.release(); in your revoker won’t work. I suggest
>> using InterProcessSemaphoreMutex instead.
>>
>>  -JZ
>>
>>
>> On September 30, 2014 at 4:19:58 PM, Singer, Jill (
>> jill.singer@pearson.com) wrote:
>>
>>   short:  I want to create a lock with one client and release it with
>> another; so I am trying to use revocation for that end.  It isn't working.
>>  more details (and my code) are below.
>> any help is appreciated!
>>
>>
>>
>> long:  have a system where one thread (with its own client) sets the
>> first lock (update),
>>             then a second thread (with a client that may or may not be
>> the same as the original client)
>>             will set a second lock; then do some work, then release that
>> lock, and then release the first lock
>>
>>             this code simulates two threads by having two different
>> clients get locks.
>>
>>             the second client is unable to revoke the lock from the first
>> client, however.  the 'revocation listener' is never triggered.
>>             I have scoured the web and not found examples.
>>
>>             this code assumes that you have a zookeeper server running on
>> your local host at port 2181
>>
>>             ideally, I'd also like to look up from somewhere else real
>> quick to see if the lock is in place, but perhaps
>>             an acquire with a very short timeout (5 milliseconds) would
>> accomplish that.
>>
>>            also, is  it a good idea to reap away locks after releasing
>> them?  (to not clog up the system?)
>>
>> thanks
>>
>> -Jill
>>
>> ps:  also posted on stack overflow.
>>
>> I'll cross-post answers if I have them.
>>  >>>>>>>>>>>>>
>>  import java.util.Collection;
>> import java.util.List;
>> import java.util.concurrent.TimeUnit;
>> import org.apache.curator.RetryPolicy;
>> import org.apache.curator.framework.CuratorFramework;
>> import org.apache.curator.framework.CuratorFrameworkFactory;
>> import org.apache.curator.framework.recipes.locks.InterProcessMutex;
>> import org.apache.curator.framework.recipes.locks.RevocationListener;
>> import org.apache.curator.framework.recipes.locks.Revoker;
>> import org.apache.curator.retry.ExponentialBackoffRetry;
>>
>> public class MultipleClientExample {
>>
>>
>>     /*entry point
>>      */
>>     public static void main(String[] args){
>>
>>         RetryPolicy retryPolicy = new ExponentialBackoffRetry(1000, 3);
>>         String zookeeperConnectionString = "127.0.0.1:2181";
>>         CuratorFramework client =
>> CuratorFrameworkFactory.newClient(zookeeperConnectionString, retryPolicy);
>>         client.start();
>>
>>         try {
>>             System.out.println("testing locks....");
>>
>>             InterProcessMutex ipMutex = new InterProcessMutex(client,
>> "/mpx-updates/guid123/update");
>>
>>             boolean acquired = ipMutex.acquire(3, TimeUnit.SECONDS);
>>             System.out.println("got the lock(update)?" + acquired);
>>
>>             RevocationListener<InterProcessMutex> rl = new
>> MyRevocationListener();
>>
>>             ipMutex.makeRevocable(rl);
>>
>>             InterProcessMutex ipMutex2 = new InterProcessMutex(client,
>> "/mpx-updates/guid123/swap");
>>             boolean a2 = ipMutex2.acquire(3, TimeUnit.SECONDS);
>>             System.out.println("got the lock(swap)?" + a2);
>>
>>             System.out.println("got the first lock in this process? " +
>> ipMutex.isAcquiredInThisProcess());
>>
>>             // make a new client; see if it can get the lock!
>>             CuratorFramework client2 =
>> CuratorFrameworkFactory.newClient(zookeeperConnectionString, retryPolicy);
>>             client2.start();
>>
>>             InterProcessMutex ipMutex1Retry = new
>> InterProcessMutex(client2, "/mpx-updates/guid123/update");
>>             boolean a3 = ipMutex1Retry.acquire(3, TimeUnit.SECONDS);
>>             System.out.println("got the lock(retry/update) ?" + a3);
>>
>>             System.out.println("got the first lock in this process? " +
>> ipMutex1Retry.isAcquiredInThisProcess());
>>
>>             Revoker.attemptRevoke(client2, "/mpx-updates/guid123/update");
>>             a3 = ipMutex1Retry.acquire(3, TimeUnit.SECONDS);
>>             System.out.println("AGAIN: got the lock(retry/update) ?" +
>> a3);
>>
>>         } catch (Exception e) {
>>             // TODO Auto-generated catch block
>>             e.printStackTrace();
>>         }
>>
>>     }
>>
>>     public class MyRevocationListener implements
>> RevocationListener<InterProcessMutex> {
>>
>>         /*
>>          * (non-Javadoc)
>>          *
>>          * @see
>> org.apache.curator.framework.recipes.locks.RevocationListener#revocationRequested(java.lang.Object)
>>          */
>>         @Override
>>         public void revocationRequested(InterProcessMutex lock) {
>>
>>             //this seems to never be called
>>
>>             Collection<String> participantNodes = null;
>>
>>             try {
>>                 System.out.println("revocation was requested....");
>>                 System.out.println("ick ick revocation requested....");
>>                 participantNodes = lock.getParticipantNodes();
>>                 lock.release();
>>                 System.out.println("revoked lock at path: " +
>> participantNodes);
>>             } catch (Exception e) {
>>                 System.out.println("problem revoking lock with path: " +
>> participantNodes + "; it was not revoked");
>>             }
>>
>>         }
>>
>>     }
>> }
>>
>>
>

Re: revocation not working

Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
* Damn - looks like getLockPath() is protected. That should be corrected. For now, create a subclass that has a new method that returns the lock path.

* the  InterProcessSemaphoreMutex does not allow revoking; so how will that help?
Damn again. Instead, you’ll need to interrupt the thread that owns the lock.

I apologize about the lack of features here. Apparently, this hasn’t been used very much. A PR with improvements would be appreciated.

-JZ

On October 1, 2014 at 9:44:13 AM, Singer, Jill (jill.singer@pearson.com) wrote:

Jordan-

    thanks for the advice!

Here are my follow-up questions:

* I can't find the 'getLockPath()"  method on the InterProcessMutex or  InterProcessSemaphoreMutex class
(I looked here: https://curator.apache.org/apidocs/index.html and couldn't find a 'getLockPath()" method anywhere (the docs are version 2.5.1-snapshot, btw)
(I am using curator version 2.5.0)

* the  InterProcessSemaphoreMutex does not allow revoking; so how will that help?

On Tue, Sep 30, 2014 at 8:46 PM, Jordan Zimmerman <jo...@jordanzimmerman.com> wrote:
There are a number of problems:

* The docs are not clear on this, but makeRevocable() must be called BEFORE the lock is acquired. Please submit a Jira/PR to fix the doc.
* In your test, Revoker.attemptRevoke was using the incorrect path. It must be the path of the lock, so: "Revoker.attemptRevoke(client2, ipMutex.getLockPath());”
* InterProcessMutex keeps track of the thread that owns the lock. So, the lock.release(); in your revoker won’t work. I suggest using InterProcessSemaphoreMutex instead.

-JZ


On September 30, 2014 at 4:19:58 PM, Singer, Jill (jill.singer@pearson.com) wrote:

short:  I want to create a lock with one client and release it with another; so I am trying to use revocation for that end.  It isn't working.  more details (and my code) are below.
any help is appreciated!



long:  have a system where one thread (with its own client) sets the first lock (update),
            then a second thread (with a client that may or may not be the same as the original client)
            will set a second lock; then do some work, then release that lock, and then release the first lock

            this code simulates two threads by having two different clients get locks.

            the second client is unable to revoke the lock from the first client, however.  the 'revocation listener' is never triggered.
            I have scoured the web and not found examples.

            this code assumes that you have a zookeeper server running on your local host at port 2181

            ideally, I'd also like to look up from somewhere else real quick to see if the lock is in place, but perhaps 
            an acquire with a very short timeout (5 milliseconds) would accomplish that.

           also, is  it a good idea to reap away locks after releasing them?  (to not clog up the system?)

thanks

-Jill

ps:  also posted on stack overflow.

I'll cross-post answers if I have them.
>>>>>>>>>>>>>
import java.util.Collection;
import java.util.List;
import java.util.concurrent.TimeUnit;
import org.apache.curator.RetryPolicy;
import org.apache.curator.framework.CuratorFramework;
import org.apache.curator.framework.CuratorFrameworkFactory;
import org.apache.curator.framework.recipes.locks.InterProcessMutex;
import org.apache.curator.framework.recipes.locks.RevocationListener;
import org.apache.curator.framework.recipes.locks.Revoker;
import org.apache.curator.retry.ExponentialBackoffRetry;

public class MultipleClientExample {


    /*entry point
     */
    public static void main(String[] args){

        RetryPolicy retryPolicy = new ExponentialBackoffRetry(1000, 3);
        String zookeeperConnectionString = "127.0.0.1:2181";
        CuratorFramework client = CuratorFrameworkFactory.newClient(zookeeperConnectionString, retryPolicy);
        client.start();

        try {
            System.out.println("testing locks....");

            InterProcessMutex ipMutex = new InterProcessMutex(client, "/mpx-updates/guid123/update");

            boolean acquired = ipMutex.acquire(3, TimeUnit.SECONDS);
            System.out.println("got the lock(update)?" + acquired);

            RevocationListener<InterProcessMutex> rl = new MyRevocationListener();

            ipMutex.makeRevocable(rl);

            InterProcessMutex ipMutex2 = new InterProcessMutex(client, "/mpx-updates/guid123/swap");
            boolean a2 = ipMutex2.acquire(3, TimeUnit.SECONDS);
            System.out.println("got the lock(swap)?" + a2);

            System.out.println("got the first lock in this process? " + ipMutex.isAcquiredInThisProcess());

            // make a new client; see if it can get the lock!
            CuratorFramework client2 = CuratorFrameworkFactory.newClient(zookeeperConnectionString, retryPolicy);
            client2.start();

            InterProcessMutex ipMutex1Retry = new InterProcessMutex(client2, "/mpx-updates/guid123/update");
            boolean a3 = ipMutex1Retry.acquire(3, TimeUnit.SECONDS);
            System.out.println("got the lock(retry/update) ?" + a3);

            System.out.println("got the first lock in this process? " + ipMutex1Retry.isAcquiredInThisProcess());

            Revoker.attemptRevoke(client2, "/mpx-updates/guid123/update");
            a3 = ipMutex1Retry.acquire(3, TimeUnit.SECONDS);
            System.out.println("AGAIN: got the lock(retry/update) ?" + a3);

        } catch (Exception e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
        }

    }

    public class MyRevocationListener implements RevocationListener<InterProcessMutex> {

        /*
         * (non-Javadoc)
         * 
         * @see org.apache.curator.framework.recipes.locks.RevocationListener#revocationRequested(java.lang.Object)
         */
        @Override
        public void revocationRequested(InterProcessMutex lock) {

            //this seems to never be called 

            Collection<String> participantNodes = null;

            try {
                System.out.println("revocation was requested....");
                System.out.println("ick ick revocation requested....");
                participantNodes = lock.getParticipantNodes();
                lock.release();
                System.out.println("revoked lock at path: " + participantNodes);
            } catch (Exception e) {
                System.out.println("problem revoking lock with path: " + participantNodes + "; it was not revoked");
            }

        }

    }
}



Re: revocation not working

Posted by "Singer, Jill" <ji...@pearson.com>.
Jordan-

    thanks for the advice!

Here are my follow-up questions:

* I can't find the 'getLockPath()"  method on the InterProcessMutex or
 InterProcessSemaphoreMutex
class
(I looked here: https://curator.apache.org/apidocs/index.html and couldn't
find a 'getLockPath()" method anywhere (the docs are version
2.5.1-snapshot, btw)
(I am using curator version 2.5.0)

* the  InterProcessSemaphoreMutex does not allow revoking; so how will that
help?

On Tue, Sep 30, 2014 at 8:46 PM, Jordan Zimmerman <
jordan@jordanzimmerman.com> wrote:

> There are a number of problems:
>
> * The docs are not clear on this, but makeRevocable() must be called
> BEFORE the lock is acquired. Please submit a Jira/PR to fix the doc.
> * In your test, Revoker.attemptRevoke was using the incorrect path. It
> must be the path of the lock, so: "Revoker.attemptRevoke(client2,
> ipMutex.getLockPath());”
> * InterProcessMutex keeps track of the thread that owns the lock. So,
> the lock.release(); in your revoker won’t work. I suggest
> using InterProcessSemaphoreMutex instead.
>
> -JZ
>
>
> On September 30, 2014 at 4:19:58 PM, Singer, Jill (jill.singer@pearson.com)
> wrote:
>
>  short:  I want to create a lock with one client and release it with
> another; so I am trying to use revocation for that end.  It isn't working.
>  more details (and my code) are below.
> any help is appreciated!
>
>
>
> long:  have a system where one thread (with its own client) sets the first
> lock (update),
>             then a second thread (with a client that may or may not be the
> same as the original client)
>             will set a second lock; then do some work, then release that
> lock, and then release the first lock
>
>             this code simulates two threads by having two different
> clients get locks.
>
>             the second client is unable to revoke the lock from the first
> client, however.  the 'revocation listener' is never triggered.
>             I have scoured the web and not found examples.
>
>             this code assumes that you have a zookeeper server running on
> your local host at port 2181
>
>             ideally, I'd also like to look up from somewhere else real
> quick to see if the lock is in place, but perhaps
>             an acquire with a very short timeout (5 milliseconds) would
> accomplish that.
>
>            also, is  it a good idea to reap away locks after releasing
> them?  (to not clog up the system?)
>
> thanks
>
> -Jill
>
> ps:  also posted on stack overflow.
>
> I'll cross-post answers if I have them.
> >>>>>>>>>>>>>
>  import java.util.Collection;
> import java.util.List;
> import java.util.concurrent.TimeUnit;
> import org.apache.curator.RetryPolicy;
> import org.apache.curator.framework.CuratorFramework;
> import org.apache.curator.framework.CuratorFrameworkFactory;
> import org.apache.curator.framework.recipes.locks.InterProcessMutex;
> import org.apache.curator.framework.recipes.locks.RevocationListener;
> import org.apache.curator.framework.recipes.locks.Revoker;
> import org.apache.curator.retry.ExponentialBackoffRetry;
>
> public class MultipleClientExample {
>
>
>     /*entry point
>      */
>     public static void main(String[] args){
>
>         RetryPolicy retryPolicy = new ExponentialBackoffRetry(1000, 3);
>         String zookeeperConnectionString = "127.0.0.1:2181";
>         CuratorFramework client =
> CuratorFrameworkFactory.newClient(zookeeperConnectionString, retryPolicy);
>         client.start();
>
>         try {
>             System.out.println("testing locks....");
>
>             InterProcessMutex ipMutex = new InterProcessMutex(client,
> "/mpx-updates/guid123/update");
>
>             boolean acquired = ipMutex.acquire(3, TimeUnit.SECONDS);
>             System.out.println("got the lock(update)?" + acquired);
>
>             RevocationListener<InterProcessMutex> rl = new
> MyRevocationListener();
>
>             ipMutex.makeRevocable(rl);
>
>             InterProcessMutex ipMutex2 = new InterProcessMutex(client,
> "/mpx-updates/guid123/swap");
>             boolean a2 = ipMutex2.acquire(3, TimeUnit.SECONDS);
>             System.out.println("got the lock(swap)?" + a2);
>
>             System.out.println("got the first lock in this process? " +
> ipMutex.isAcquiredInThisProcess());
>
>             // make a new client; see if it can get the lock!
>             CuratorFramework client2 =
> CuratorFrameworkFactory.newClient(zookeeperConnectionString, retryPolicy);
>             client2.start();
>
>             InterProcessMutex ipMutex1Retry = new
> InterProcessMutex(client2, "/mpx-updates/guid123/update");
>             boolean a3 = ipMutex1Retry.acquire(3, TimeUnit.SECONDS);
>             System.out.println("got the lock(retry/update) ?" + a3);
>
>             System.out.println("got the first lock in this process? " +
> ipMutex1Retry.isAcquiredInThisProcess());
>
>             Revoker.attemptRevoke(client2, "/mpx-updates/guid123/update");
>             a3 = ipMutex1Retry.acquire(3, TimeUnit.SECONDS);
>             System.out.println("AGAIN: got the lock(retry/update) ?" + a3);
>
>         } catch (Exception e) {
>             // TODO Auto-generated catch block
>             e.printStackTrace();
>         }
>
>     }
>
>     public class MyRevocationListener implements
> RevocationListener<InterProcessMutex> {
>
>         /*
>          * (non-Javadoc)
>          *
>          * @see
> org.apache.curator.framework.recipes.locks.RevocationListener#revocationRequested(java.lang.Object)
>          */
>         @Override
>         public void revocationRequested(InterProcessMutex lock) {
>
>             //this seems to never be called
>
>             Collection<String> participantNodes = null;
>
>             try {
>                 System.out.println("revocation was requested....");
>                 System.out.println("ick ick revocation requested....");
>                 participantNodes = lock.getParticipantNodes();
>                 lock.release();
>                 System.out.println("revoked lock at path: " +
> participantNodes);
>             } catch (Exception e) {
>                 System.out.println("problem revoking lock with path: " +
> participantNodes + "; it was not revoked");
>             }
>
>         }
>
>     }
> }
>
>