ConcurrentModificationException in org.jboss.ha.jndi.Detache

[kkoster]

I am getting intermittent exceptions (stack trace to follow) on the server side when using HA JNDI any a moderate number of multithreaded clients that have fairly uniform request profiles from the server.

I am using JBoss 4.0.3RC1 with EJB3 RC1. Any constructive help would be appreciated.

The stack trace is as follows:


11:40:10,326 WARN [RunnableTaskWrapper] Unhandled throwable for runnable: org.jboss.ha.jndi.DetachedHANamingService$BootstrapRequestHandler@10374bf
java.util.ConcurrentModificationException
at java.util.ArrayList.writeObject(ArrayList.java:573)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:890)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1333)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1284)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1073)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:291)
at org.jboss.ha.framework.interfaces.HARMIClient.writeObject(HARMIClient.java:250)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:890)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1333)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1284)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1073)
at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1369)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1341)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1284)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1073)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:291)
at java.rmi.MarshalledObject.(MarshalledObject.java:92)
at org.jboss.ha.jndi.DetachedHANamingService$BootstrapRequestHandler.run(DetachedHANamingService.java:676)
at org.jboss.util.threadpool.RunnableTaskWrapper.run(RunnableTaskWrapper.java:134)
at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:748)
at java.lang.Thread.run(Thread.java:595)

[starksm64]

There is a fix for this issue in 4.0.3RC2, so try that.
http://jira.jboss.com/jira/browse/JBAS-1823

[kkoster]

Apparently this is not fixed. I have moved to 4.0.3RC2 and am still getting the following stack trace when a moderate number of clients (~60) attempt to access a common set of services.


07:56:13,812 WARN [RunnableTaskWrapper] Unhandled throwable for runnable: org.j
boss.ha.jndi.DetachedHANamingService$BootstrapRequestHandler@477559
java.util.ConcurrentModificationException
at java.util.ArrayList.writeObject(ArrayList.java:573)
at sun.reflect.GeneratedMethodAccessor94.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:890)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1333)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1284)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1073)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:291)
at org.jboss.ha.framework.interfaces.HARMIClient.writeObject(HARMIClient.java:250)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:890)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1333)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1284)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1073)
at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1369)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1341)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1284)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1073)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:291)
at java.rmi.MarshalledObject.(MarshalledObject.java:92)
at org.jboss.ha.jndi.DetachedHANamingService$BootstrapRequestHandler.run(DetachedHANamingService.java:676)
at org.jboss.util.threadpool.RunnableTaskWrapper.run(RunnableTaskWrapper.java:134)
at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:748)
at java.lang.Thread.run(Thread.java:595)

[kkoster]

This seems to be related to the other post I made regarding communication exceptions using the same naming context in multiple threads. Apparently, at times, multiple calls to the same naming context make it to the server simulatneously causing this problem. As soon as the lookup calls where synchronized, the problem stopped.

[jim.paterson]

Can you clarify what your previous post means. I'm seeing the same issue with JBoss 4.0.3RC2. Our client does make occasional server calls in different threads. Are you saying these have to be synchronised to stop different threads calling through the same InitialContext of remote stubs at the same time?

[kkoster]

It seems so. I have an initial high volume of calls via 60 or so threads. Almost immediately this exception occurs. When I synchronized the calls. The problem went away. Intermittent calls on multiple threads may not experience this problem if the lookup calls do not collide with one another.

[darranl]

The API for the InitialContext does warn that the implementation is not required to be thread safe and the calling application should synchronize to prevent concurrent access.