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-boun...@lists.jboss.org [mailto:infinispan-dev-boun...@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<vblag...@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@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev@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. _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
