Re: [infinispan-dev] Key locking order in LockingInterceptor

Which threads are involved here in the potential deadlock you're talking about? I'm not sure we could enforce comparable keys since they're outside of the scope of what we can control and keys might not be comparable at all. Using Comparable though in a test, you might be able to figure out whether the issue is caused by ordering. I.e. you could have two keys which order is swapped at runtime. However, even without using Comparable, it should be relatively easy to spot an issue with locking ordering in the logs (assuming thread info is in logs) cos LockManagerImpl.lockAndRecord logs attempts to locks and whether these were successful. ----- "Vladimir Blagojevic" <vblagoje(a)redhat.com&gt; wrote: > Hi, > > I am trying to figure out why SingleJoinTask sometimes fails due to > TimeoutException. I noticed that invalidate command sends out bunch of > keys to be invalidated across cluster and in turn LockingInterceptor > tries to lock these keys one by one. In few other methods > LockingInterceptor also tries to lock a list of keys sequentially. > Without knowing the full details of locking mechanism this practice > seems to be dangerously susceptible to deadlocks. Shouldn't we require > all keys to be Comparable so that we can order keys prior to any > locking attempts in LockingInterceptor. > > Maybe I am not understand all the details; I would like to be proven > that I am completely off :) > > Regards, > Vladimir > > > _______________________________________________ > 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