probable bug discovered --- failure acquiring lock

[indrit]

Hello,

I have the following problem:

using jboss cache as a simple container for the GT tickets of a CAS server on a cluster based upon WebSphere 6 application server and running on two Solaris machines I'm getting on one of these machines an exception(please see the bottom of this page) when adding a new entry on the cache. I'm using the following config:

<attribute name="TransactionManagerLookupClass">org.jboss.cache.GenericTransactionManagerLookup</attribute>
<attribute name="NodeLockingScheme">PESSIMISTIC</attribute>
<attribute name="IsolationLevel">READ_UNCOMMITTED</attribute>

It seems the the code try to synchronise over a QueuedSemaphore object and waits for a notify that never arrives....

Can be this a jboss cache bug (because for some reason maybe a lock over the tree hasn't been released...) ??

The exception is:

ERROR JBossCacheTicketRegistry:50
 - org.jboss.cache.lock.TimeoutException: failure acquiring lock: fqn=/ticket, caller=Thread[WebCon
tainer : 0,5,main], lock=write owner=GlobalTransaction:<"IP ADDRESS:PORT">:191 (org.jboss.cache.lo
ck.LockStrategyReadUncommitted@13f82ef)
org.jboss.cache.lock.TimeoutException: failure acquiring lock: fqn=/ticket, caller=Thread[WebContai
ner : 0,5,main], lock=write owner=GlobalTransaction:<"IP ADDRESS:PORT">:191 (org.jboss.cache.lock.
LockStrategyReadUncommitted@13f82ef)
 at org.jboss.cache.Node.acquire(Node.java:407)
 at org.jboss.cache.interceptors.PessimisticLockInterceptor.lock(PessimisticLockInterceptor.
java:228)
 at org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockIntercepto
r.java:160)
 at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
 at org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:32)
 at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
 at org.jboss.cache.interceptors.ReplicationInterceptor.invoke(ReplicationInterceptor.java:3
4)
 at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
 at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:345)
 at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:156)
 at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
 at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:157)
 at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5520)
 at org.jboss.cache.TreeCache.put(TreeCache.java:3678)
 at org.jboss.cache.TreeCache.put(TreeCache.java:3616)
 at org.jasig.cas.ticket.registry.JBossCacheTicketRegistry.addTicket(JBossCacheTicketRegistr
y.java:48)
 at org.jasig.cas.CentralAuthenticationServiceImpl.createTicketGrantingTicket(CentralAuthent
icationServiceImpl.java:290)
......
........
Caused by: org.jboss.cache.lock.TimeoutException: write lock for /ticket could not be acquired afte
r 10000 ms. Locks: Read lock owners: []
Write lock owner: GlobalTransaction:<"IP ADDRESS:PORT">:191
 (caller=Thread[WebContainer : 0,5,main], lock info: write owner=GlobalTransaction:
 <"IP ADDRESS:PORT">:191 (org.jboss.cache.lock.LockStrategyReadUncommitted@13f82ef))
 at org.jboss.cache.lock.IdentityLock.acquireWriteLock(IdentityLock.java:202)
 at org.jboss.cache.Node.acquireWriteLock(Node.java:431)
 at org.jboss.cache.Node.acquire(Node.java:386)
 ... 50 more

[ben.wang]

This just says it encounters a lock timeout. Currently the write lock owner is: GlobalTransaction:<"IP ADDRESS:PORT">:191 and the caller thread is "caller=Thread[WebContainer : 0,5,main]".


How do you use the cache specifically? Does this happen every time?

[indrit]

thanks for answering!

It happened sistematically until I restarted the application server where the error occurred. It seemed to me that for some reason a previews lock wasn't released, may be some exception was the cause. What do you think?

[indrit]

We are using the jboss cache as a CAS's ticket repository. Actually a granting ticket (CAS entity) is created when a user logins on our site, and this ticket must be propagated to the other application server on the cluster. On user logoff the ticket is destroyed. The problem happened on a test environment so there was little traffic and low load average.