curator-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From tathagata roy <tatha....@gmail.com>
Subject Re: Apache Curator Shared Lock Revoking fails
Date Wed, 28 Oct 2015 20:01:34 GMT
Thanks I will try that out

On Wed, Oct 28, 2015 at 4:00 PM, Jordan Zimmerman <
jordan@jordanzimmerman.com> 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 <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> 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> 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