EDIT: Originally posted in the wrong thread. I blame Outlook.
I guess I qualify as "others", since I'm looking at similar issues.
Got read lock
java.util.concurrent.TimeoutException: Thread-1 could not obtain exclusive processing lock
after 3 seconds. Locks in question are
java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock@16aa37a6[Read locks = 1] and
java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock@12b7eea[Unlocked]
This is on the latest master.
Erik
-----Original Message-----
From: infinispan-dev-bounces(a)lists.jboss.org
[mailto:infinispan-dev-bounces@lists.jboss.org] On Behalf Of Vladimir Blagojevic
Sent: Monday, May 16, 2011 4:25 PM
To: infinispan -Dev List
Cc: Manik Surtani
Subject: Re: [infinispan-dev] JGroupsDistSync and ISPN-83
Manik (and others),
Can you run this code on your laptops and let me know what happened!
Vladimir
public static void main (String [] arg) throws Exception {
final JGroupsDistSync ds = new JGroupsDistSync();
ds.acquireProcessingLock(false, 3, TimeUnit.SECONDS);
System.out.println("Got read lock");
Thread t = new Thread(){
public void run (){
try {
ds.acquireProcessingLock(true, 3, TimeUnit.SECONDS);
System.out.println("Got write lock");
} catch (TimeoutException e) {
System.out.println(e);
}
}
};
t.start();
}
On 11-05-13 4:53 PM, Manik Surtani wrote:
Yes, please have a look. If we are relying on lock upgrades then
that's really bad. I am aware of the inability to (safely) upgrade a RWL and I'm
pretty sure we don't try, but the dist sync codebase has evolved a lot and could do
with some careful analysis.
Sent from my mobile phone
On 12 May 2011, at 09:24, Vladimir Blagojevic<vblagoje(a)redhat.com> wrote:
> On 11-05-11 11:23 AM, Dan Berindei wrote:
>> If ReentrantReadWriteLock would allow upgrades then you would get a
>> deadlock when two threads both hold the read lock and try to upgrade
>> to a write lock at the same time.
>> There's always a trade-off...
>>
>> I'm not familiar with the code, but are you sure the read lock is
>> being held by the same thread that is trying to acquire the write
>> lock?
>>
> Not sure and it sounds counter intuitive that a thread holding a read
> lock from cluster invocation is doing state generation for state
> transfer as well. But this lock business is fishy and I plan to get
> to the bottom of it...
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
The information contained in this message is legally privileged and confidential, and is
intended for the individual or entity to whom it is addressed (or their designee). If this
message is read by anyone other than the intended recipient, please be advised that
distribution of this message, in any form, is strictly prohibited. If you have received
this message in error, please notify the sender immediately and delete or destroy all
copies of this message.