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:59:13 GMT
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");
>>>>             }
>>>>
>>>>         }
>>>>
>>>>     }
>>>> }
>>>>
>>>>
>>>
>>
>

Mime
View raw message