Lock timeout during sync replication
miketee May 4, 2006 10:16 AMHi all,
I am currently evaluating JBoss Cache 1.3.0.SP1 (yes, I am new with it) for our next project. I wrote a little stress test to get a feeling for the possible throughput of the replication between two nodes on different machines. The stress test uses a configurable number of threads updating the cache (whereby the data records hardly interfere).
But since I moved the thread counter in the cache I have synchronization and locking problems. The starting threads cause a high concurrency load. Without transactions I recognized either lost updates or sometimes locking exceptions. So I introduced trancactions (DummyUserTransaction) but this strengthened the locking problem: only a few threads (1 to 4 of 20) are able to access the thread counter, all others get a org.jboss.cache.lock.TimeoutException (even if I set the LockAcquisitionTimeout to 120000 ms):
[java] org.jboss.cache.lock.TimeoutException: read lock for /global/config could not be acquired by GlobalTransacti
on:<172.17.64.64:1413>:27 after 10000 ms. Locks: Read lock owners: {}
[java] Write lock owner: GlobalTransaction:<172.17.64.64:1413>:26
[java] , lock info: write owner=GlobalTransaction:<172.17.64.64:1413>:26 (activeReaders=0, activeWriter=Thread[DebitThread6,5,AccountThreads], waitingReaders=3, waitingWriters=0, waitingUpgrader=0)
[java] at org.jboss.cache.lock.IdentityLock.acquireReadLock(IdentityLock.java:240)
[java] at org.jboss.cache.Node.acquireReadLock(Node.java:544)
[java] at org.jboss.cache.Node.acquire(Node.java:515)
[java] at org.jboss.cache.interceptors.PessimisticLockInterceptor.lock(PessimisticLockInterceptor.java:202)
[java] at org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:138)
[java] at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:67)
[java] at org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:32)
[java] at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:67)
[java] at org.jboss.cache.interceptors.ReplicationInterceptor.invoke(ReplicationInterceptor.java:24)
[java] at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:67)
[java] at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:321)
[java] at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:136)
[java] at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:67)
[java] at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:133)
[java] at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:4804)
[java] at org.jboss.cache.TreeCache.get(TreeCache.java:3040)
[java] at org.jboss.cache.TreeCache.get(TreeCache.java:3021)
[java] at org.jboss.cache.aop.CacheInterceptor.invoke(CacheInterceptor.java:111)
[java] at org.jboss.aop.joinpoint.FieldReadInvocation.invokeNext(FieldReadInvocation.java:48)
[java] at de.ic3s.evaluation.jbosscache.cacheable.Configuration.threadCnt_r_$aop(Configuration.java)
[java] at de.ic3s.evaluation.jbosscache.cacheable.Configuration.setThreadCntUp(Configuration.java:48)
[java] at de.ic3s.evaluation.jbosscache.Runner$AccountThread.incThreadCount(Runner.java:239)
[java] at de.ic3s.evaluation.jbosscache.Runner$AccountThread.run(Runner.java:294)
[java] at java.lang.Thread.run(Thread.java:595)
protected synchronized void incThreadCount() { short threadCnt = -1; UserTransaction tx = new DummyUserTransaction(DummyTransactionManager.getInstance()); try { Configuration configuration = (Configuration)cache.getObject("/global/config"); tx.begin(); threadCnt = configuration.setThreadCntUp(); // increments the thread counter tx.commit(); } catch (Exception e) { printThreadMsg(e.getMessage(), e); try { tx.rollback(); } catch(Throwable t) {} } printThreadMsg("ThreadCount++ = " + threadCnt); }
I am using the META-INF/replSync-service.xml from the examples to configure the cache.
How can I get rid of these locks and maintain the cache to be synchronous? No lock seems to be removed after the commit of the transaction.
Thanks
Mike