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 < [email protected]> wrote: > Correct > > > On October 1, 2014 at 10:07:22 AM, Singer, Jill ([email protected]) > 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 < > [email protected]> 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 ([email protected]) >> 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 < >> [email protected]> 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 ( >>> [email protected]) 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"); >>> } >>> >>> } >>> >>> } >>> } >>> >>> >> >
