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:01 GMT
You could have an object of some kind that signals that the holding thread should release the
lock. The object could have the ID of the lock. Something like that.

-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