Resolving locking issues and timeout exception

[sudheerk84]

i am getting the following exception in my setup.

org.infinispan.util.concurrent.TimeoutException: Unable to acquire lock after [10 seconds] on key [17] for requestor [GlobalTransaction:<devserver-19273>:3128:local]! Lock held by [GlobalTransaction:<devserver-19273>:3130:local]

i use the default locking settings , and use transations (atomikos) to manage state across infinispam and mysql.I have lockstriping enabled and would like to maintain it for scalability purposes.

I am interestd in knowing the exact cause of this wait. As in which thread locked the particular key.  The error statement was not very helpful in getting these details. I have enabled logging mode to debug. Hopefully next time i get this issue it shoudl be giving me more helpful logs .Is there anything else i can do to get more info ?

i would be interestd to know which thread has locked it and also on what key of teh cache. I did check teh details in jmx console but could not fidn much information. I was more interested in seeing a view similar to a theard dump where i can see which thread has been blocked on the monitor.

[sudheerk84]

this keeps repeating in my setup .

My usescase is as follows.

I have around 220 threads trying to update 220 different keys on the cache. When this happens i get a lot of this locking issues.

In an attemp to solve this i tried to increase teh concurrency level by increasing teh number of locks to 500, still i dont see any benefit.

<locking isolationLevel="REPEATABLE_READ" concurrencyLevel="5000" />

When i see teh jmx console when 220 threads update this , i see only 4 or 5 locks are being used.

When i set the useLockStriping="false" , then it seems to work fine. i see that the number of locks being used go upto 100.

[dan.berindei]

What keys are you using? If you're using custom keys it could be that there are much fewer distinct hashcode values than there are keys. Lock striping assigns locks to keys based on the key's hashcode, so you could actually be using only a small subset of the 500 keys.

If you see the problem with unique strings as keys, this sounds like a problem with lock striping. Please raise a JIRA and attach a test case if you can.

[mircea.markus]

I have lockstriping enabled and would like to maintain it for scalability purposes.

lockstriping won't bring you scalability, but it lowers the memory consumptions. If memory is not an issue for you I suggest disabling it.