Well, InterProcessSemaphoreMutex has the isAcquiredInThisProcess() method. Also, you could just catch IllegalStateException and log it. If you continue to have trouble, I can write an example for you when I have some time.
-JZ > On Oct 28, 2015, at 4:46 PM, tathagata roy <[email protected]> wrote: > > Jordan, > > I tried using InterProcessSemaphoreMutex but that too has problems which are > > If the 2nd thread creates a lock object on the basepath and without acquiring > it and tries to release it, the Exception java.lang.IllegalStateException: > Not acquired is thrown. And the 2nd thread is not able to acquire the lock in > itself without releasing it. > > Also if we go by the first approach you suggested of some kind of > intercommunication between threads, that would be a problem in real time as > instead of the threads being in the same JVM, the threads can be in separate > JVMs. So we cant notify threads running on a different JVM. > > Do you think we can achieve this using the native zookeeper api? > > Note: i am using version 2.8.0 > > Thanks for all your help and suggestions > > > > On Wed, Oct 28, 2015 at 4:01 PM, tathagata roy <[email protected] > <mailto:[email protected]>> wrote: > Thanks I will try that out > > On Wed, Oct 28, 2015 at 4:00 PM, Jordan Zimmerman <[email protected] > <mailto:[email protected]>> wrote: > Another thing is to use InterProcessSemaphoreMutex instead. It is a > non-reentrant lock and can be unlocked from any thread. > > -JZ > >> On Oct 28, 2015, at 2:55 PM, tathagata roy <[email protected] >> <mailto:[email protected]>> wrote: >> >> Thanks Jordan for the response. >> >> I cannot use the strategy because the thread can hold multiple locks , and >> if i do that it will release all the locks. The example i have put in the >> question is just a sample i was trying but in the actual project a single >> thread holds multiple locks. >> >> Is there any other way i can do that? >> >> On Wed, Oct 28, 2015 at 3:43 PM, Jordan Zimmerman >> <[email protected] <mailto:[email protected]>> wrote: >> Your RevocationListener should interrupt the thread that holds the lock. >> Then, that thread can release the lock. >> >> -Jordan >> >>> On Oct 28, 2015, at 2:19 PM, tathagata roy <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> All, >>> >>> I am trying to test the revocable Locking in Apache Curator. I have two >>> threads which tries to acquire a lock. If the first test acquires the lock, >>> the second thread can ask the first thread to release the lock so that the >>> 2nd thread can acquire it >>> >>> RetryPolicy retryPolicy = new >>> ExponentialBackoffRetry(baseSleepTimeMills, maxRetries); >>> CuratorFramework client = CuratorFrameworkFactory.newClient(hosts, >>> retryPolicy); >>> client.start(); >>> >>> final InterProcessMutex lock = new InterProcessMutex(client, >>> lockBasePath); >>> >>> Collection<String> nodes = lock.getParticipantNodes(); >>> >>> lock.makeRevocable(new RevocationListener<InterProcessMutex>(){ >>> >>> @Override >>> public void revocationRequested(InterProcessMutex lock1) { >>> try { >>> if(lock.isAcquiredInThisProcess()){ >>> lock.release(); >>> } >>> >>> } catch (Exception e) { >>> // TODO Auto-generated catch block >>> e.printStackTrace(); >>> } >>> >>> } >>> >>> }); >>> >>> if(nodes!=null && !nodes.isEmpty()){ >>> Revoker.attemptRevoke(client, nodes.iterator().next()); >>> } >>> >>> if (lock.acquire(waitTimeSeconds, TimeUnit.SECONDS)) { >>> try { >>> doSomeWork(lockName); >>> } finally { >>> lock.release(); >>> } >>> } else { >>> System.err.printf("%s timed out after %d seconds waiting to >>> acquire lock on %s\n", >>> lockName, waitTimeSeconds, lockPath); >>> } >>> >>> The problem is, when the 2nd thread calls the attemptRevoke, the callback >>> async method is called on the first process, but since its a call back >>> method that's a third thread, and if that invokes the lock.release it >>> throws an Exception >>> >>> java.lang.IllegalMonitorStateException: You do not own the lock >>> >>> That is as per the api >>> >>> release() Perform one release of the mutex if the calling thread is the >>> same thread that acquired it. >>> >>> So basically this is never possible because callbacks will always be >>> another thread. Is my understanding right? Is there any other way to >>> achieve this? >>> >>> Thanks for any suggestions >>> >>> -Tatha >>> >>> >> >> > > >
