[jboss-dev-forums] [Design of JBoss Portal] - Re: portal clustering problem when using optimistic locking

[bstansberry@jboss.com]

You're seeing those because of this kind of thing on the ndoe and/or the other node:

"IncomingPacketHandler (channel=portal.hibernate)" daemon prio=1 tid=0x0000002b70482b30 nid=0x6d11 in Object.wait() [0x0000000042573000..0x0000000042575ab0]
  | 	at java.lang.Object.wait(Native Method)
  | 	- waiting on <0x0000002b2dc22680> (a org.jboss.cache.lock.ReadWriteLockWithUpgrade$WriterLock)
  | 	at org.jboss.cache.lock.ReadWriteLockWithUpgrade$WriterLock.attempt(ReadWriteLockWithUpgrade.java:389)
  | 	- locked <0x0000002b2dc22680> (a org.jboss.cache.lock.ReadWriteLockWithUpgrade$WriterLock)
  | 	at org.jboss.cache.lock.IdentityLock.acquireWriteLock(IdentityLock.java:199)
  | 	at org.jboss.cache.Node.acquireWriteLock(Node.java:562)
  | 	at org.jboss.cache.Node.acquire(Node.java:509)
  | 	at org.jboss.cache.interceptors.OptimisticLockingInterceptor.lockNodes(OptimisticLockingInterceptor.java:160)
  | 	at org.jboss.cache.interceptors.OptimisticLockingInterceptor.invoke(OptimisticLockingInterceptor.java:84)
  | 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
  | 	at org.jboss.cache.interceptors.OptimisticReplicationInterceptor.invoke(OptimisticReplicationInterceptor.java:85)
  | 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
  | 	at org.jboss.cache.interceptors.TxInterceptor.handleOptimisticPrepare(TxInterceptor.java:452)
  | 	at org.jboss.cache.interceptors.TxInterceptor.handleRemotePrepare(TxInterceptor.java:336)
  | 	at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:145)
  | 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
  | 	at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:183)
  | 	at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5919)
  | 	at org.jboss.cache.TreeCache._replicate(TreeCache.java:5196)

That thread is the one that carries messages up from the network layer to JBoss Cache.  As you can see, it's blocking waiting for a lock.  While those threads block, messages don't get transmitted, leading to the blocking you see on the other threads.

The real problem here is the 2 JBC instances are fighting over a lock -- and unnecessarily so - they are both trying to cache the same data that's been directly read from the db.  Logicaly, that needn't trigger any cluster traffic at all.  The old Hibernate 3.2.x / JBC 1.x integration code is quite poor.  Totally redone for Hibernate 3.3.  But that doesn't help you. :(

How critical is this?  I'm tempted to extract a version of the TreeCacheProvider out of the EAP code, improve it a bit and package it as an independent library.  Will help with your issue, and be a small benefit to the community. Won't be as good as the Hibernate 3.3 stuff, but better than what you've got.  But I really don't have the cycle to do it, not until AS 5 is done.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4159700#4159700

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4159700