curator-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jordan Zimmerman <jor...@jordanzimmerman.com>
Subject Re: revocation not working
Date Thu, 02 Oct 2014 15:09:06 GMT
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