Hmm, yes lets chat next week.
In general I agree with Galder in that -1 to keys being Comparable. This is a pretty poor
restriction to place on end users.
On 14 Jun 2010, at 15:20, Vladimir Blagojevic wrote:
I am still a novice in decoding these lock timeout stacktraces:( I
looked around the code to see how it might happen and then I saw this (IMHO) problem
staring back at me. I am not saying lock ordering is the the cause of this particular
problem. I do not know. Lets talk more about it next week.
On 2010-06-14, at 4:15 AM, galder(a)jboss.org wrote:
> 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
> _______________________________________________
> 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
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org