[jboss-user] [JBossCache] - java.util.ConcurrentModificationException in JBS 2.1 CR.4 ?

pcarpenter do-not-reply at jboss.com
Mon Feb 25 05:17:32 EST 2008


Hi
I am using Tree Cache (not pojo) in a stand alone project. 
I've been evaluating  an upgrade from 2.0GA to 2.1.
After evaluating jbc 2.1 CR.3,  I've upgraded to  2.1 CR.4. 
Nothing in my code was changed, only the class path. 
oddly enough, I started getting those Exceptions: 

anonymous wrote :  java.util.ConcurrentModificationException
  | 	at java.util.LinkedList$ListItr.checkForComodification(LinkedList.java:617)
  | 	at java.util.LinkedList$ListItr.next(LinkedList.java:552)
  | 	at org.jboss.cache.lock.IdentityLock.toString(IdentityLock.java:453)
  | 	at org.jboss.cache.lock.IdentityLock.toString(IdentityLock.java:430)
  | 	at org.jboss.cache.lock.IdentityLock.acquireReadLock(IdentityLock.java:270)
  | 	at org.jboss.cache.lock.IdentityLock.acquire(IdentityLock.java:493)
  | 	at org.jboss.cache.interceptors.PessimisticLockInterceptor.acquireNodeLock(PessimisticLockInterceptor.java:634)
  | 	at org.jboss.cache.interceptors.PessimisticLockInterceptor.lock(PessimisticLockInterceptor.java:513)
  | 	at org.jboss.cache.interceptors.PessimisticLockInterceptor.acquireLocksWithTimeout(PessimisticLockInterceptor.java:440)
  | 	at org.jboss.cache.interceptors.PessimisticLockInterceptor.handleGetNodeMethod(PessimisticLockInterceptor.java:393)
  | 	at org.jboss.cache.interceptors.MethodDispacherInterceptor.invoke(MethodDispacherInterceptor.java:87)
  | 	at org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:83)
  | 	at org.jboss.cache.interceptors.Interceptor.nextInterceptor(Interceptor.java:111)
  | 	at org.jboss.cache.interceptors.MethodDispacherInterceptor.invoke(MethodDispacherInterceptor.java:58)
  | 	at org.jboss.cache.interceptors.Interceptor.nextInterceptor(Interceptor.java:111)
  | 	at org.jboss.cache.interceptors.MethodDispacherInterceptor.invoke(MethodDispacherInterceptor.java:58)
  | 	at org.jboss.cache.interceptors.Interceptor.nextInterceptor(Interceptor.java:111)
  | 	at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:452)
  | 	at org.jboss.cache.interceptors.TxInterceptor.handleGetNodeMethod(TxInterceptor.java:245)
  | 	at org.jboss.cache.interceptors.MethodDispacherInterceptor.invoke(MethodDispacherInterceptor.java:87)
  | 	at org.jboss.cache.interceptors.Interceptor.nextInterceptor(Interceptor.java:111)
  | 	at org.jboss.cache.interceptors.MethodDispacherInterceptor.invoke(MethodDispacherInterceptor.java:58)
  | 	at org.jboss.cache.interceptors.Interceptor.nextInterceptor(Interceptor.java:111)
  | 	at org.jboss.cache.interceptors.InvocationContextInterceptor.invoke(InvocationContextInterceptor.java:73)
  | 	at org.jboss.cache.invocation.AbstractInvocationDelegate.invoke(AbstractInvocationDelegate.java:123)
  | 	at org.jboss.cache.invocation.AbstractInvocationDelegate.invoke(AbstractInvocationDelegate.java:64)
  | 	at org.jboss.cache.invocation.CacheInvocationDelegate.getNode(CacheInvocationDelegate.java:429)
  | 	at org.jboss.cache.invocation.NodeInvocationDelegate.getChild(NodeInvocationDelegate.java:331)
  | ......
  | 	
  | 


And while using different JBC code ...
anonymous wrote : 
  | java.util.ConcurrentModificationException
  | 	at java.util.LinkedList$ListItr.checkForComodification(LinkedList.java:617)
  | 	at java.util.LinkedList$ListItr.next(LinkedList.java:552)
  | 	at org.jboss.cache.lock.IdentityLock.toString(IdentityLock.java:453)
  | 	at org.jboss.cache.lock.IdentityLock.toString(IdentityLock.java:430)
  | 	at org.jboss.cache.lock.IdentityLock.toString(IdentityLock.java:424)
  | 	at java.lang.String.valueOf(String.java:2615)
  | 	at java.lang.StringBuilder.append(StringBuilder.java:116)
  | 	at org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:122)
  | 	at org.jboss.cache.interceptors.Interceptor.nextInterceptor(Interceptor.java:111)
  | 	at org.jboss.cache.interceptors.MethodDispacherInterceptor.invoke(MethodDispacherInterceptor.java:58)
  | 	at org.jboss.cache.interceptors.Interceptor.nextInterceptor(Interceptor.java:111)
  | 	at org.jboss.cache.interceptors.MethodDispacherInterceptor.invoke(MethodDispacherInterceptor.java:58)
  | 	at org.jboss.cache.interceptors.Interceptor.nextInterceptor(Interceptor.java:111)
  | 	at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:452)
  | 	at org.jboss.cache.interceptors.TxInterceptor.handleGetNodeMethod(TxInterceptor.java:245)
  | 	at org.jboss.cache.interceptors.MethodDispacherInterceptor.invoke(MethodDispacherInterceptor.java:87)
  | 	at org.jboss.cache.interceptors.Interceptor.nextInterceptor(Interceptor.java:111)
  | 	at org.jboss.cache.interceptors.MethodDispacherInterceptor.invoke(MethodDispacherInterceptor.java:58)
  | 	at org.jboss.cache.interceptors.Interceptor.nextInterceptor(Interceptor.java:111)
  | 	at org.jboss.cache.interceptors.InvocationContextInterceptor.invoke(InvocationContextInterceptor.java:73)
  | 	at org.jboss.cache.invocation.AbstractInvocationDelegate.invoke(AbstractInvocationDelegate.java:123)
  | 	at org.jboss.cache.invocation.AbstractInvocationDelegate.invoke(AbstractInvocationDelegate.java:64)
  | 	at org.jboss.cache.invocation.CacheInvocationDelegate.getNode(CacheInvocationDelegate.java:429)
  | 	at org.jboss.cache.invocation.NodeInvocationDelegate.getChild(NodeInvocationDelegate.java:331)
  | 	at org.jboss.cache.invocation.NodeInvocationDelegate.addChild(NodeInvocationDelegate.java:293)
  | 
  | .....
  | 

Just to be on the safe side, I've switched back to CR.3 and everything went back to normal.
I did some exploring and found that the exceptions are thrown while calling toString() in classes which inherit org.jboss.cache.interceptors.Interceptor.java, when the "trace" boonean field is  "true". I've looked for ways to set it to false, but I vould not find the log4j
configuraiton. to save time, I've hard coded "trace" to false, and rebuilt the jboss-code.jar from source,  this seemed to do the trick. 


public abstract class Interceptor implements InterceptorMBean
  | {
  |    protected Interceptor next = null, last = null;
  |    protected CacheSPI<?, ?> cache;
  |    protected Log log = null;
  |    protected Configuration configuration;
  |    private boolean statsEnabled = false;
  |    protected boolean trace = false;
  | 
  |    public Interceptor()
  |    {
  |       initLogger();
  |    }
  | 
  |    protected void initLogger()
  |    {
  |       log = LogFactory.getLog(getClass());
  | //      trace = log.isTraceEnabled();
  |    
  |    }


Is it a bug? I couln't find any info in the JIRA. 
if so, what is the proper way to config trace to false?

Regards and Thanks.
Paul.






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

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



More information about the jboss-user mailing list