curator-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jordan Zimmerman <jor...@jordanzimmerman.com>
Subject Re: Apache Curator Shared Lock Revoking fails
Date Wed, 28 Oct 2015 20:00:42 GMT
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 <tatha.roy@gmail.com> 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 <jordan@jordanzimmerman.com <mailto:jordan@jordanzimmerman.com>>
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 <tatha.roy@gmail.com <mailto:tatha.roy@gmail.com>>
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
>>        
>> 
> 
> 


Mime
View raw message