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#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...