curator-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Singer, Jill" <jill.sin...@pearson.com>
Subject Re: revocation not working
Date Thu, 02 Oct 2014 15:07:16 GMT
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");
>>>             }
>>>
>>>         }
>>>
>>>     }
>>> }
>>>
>>>
>>
>

Mime
View raw message