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> 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