9:31 a.m.
[ http://jira.jboss.com/jira/browse/JBJMX-45?page=comments#action_12349435 ]
Steve Gibson commented on JBJMX-45:
-----------------------------------
I don't see any links to other issues here, but what happened to the second part of
the issue - from the bug description:
suspect that there is a second order synchronization
problem in the processing of any HashSet retrieved from
the packagesMap. The retrieved HashSet may be
concurrently modified if a class loader is added or
removed while the set is being processed. The
modifications to the HashSet's in the packagesMap
performed in the add/remove class loader code path are
performed while holding the packagesMap lock, but the
code in getResourceFromRepository and
LoadMgr3.beginLoadTask, which retrieves a package set
using the getPackageClassLoaders method, is
unsynchronized. Unless there is some other lock that
makes this a non-issue, I suspect that fixing the
problem will require either making a copy of the
HashSet or a moderate amount of code restructuring.
I experienced this issue in production last week and tracked it down to LoadMgr3 as
described in the issue.
Basically, LoadMgr3.beginLoadTask retrieves a Set from the repository
(UnifiedLoadRepository3) and uses an iterator to search for the correct classloader. The
iterator is coming from java.util.TreeSet, so concurrent modification can occur when an
EJB event triggers a class lookup while startup is still occurring. (Sorry if this is all
overly vague).
We are running JBoss 4.0.2, but I see the problem code in the trunk.
Stack Trace (snippet):
2006-12-29 12:13:35,633 INFO [HibernateServiceMBean] stopping service
2006-12-29 12:13:35,636 INFO [STDOUT] Exception in thread "Queue0"
2006-12-29 12:13:35,639 INFO [NamingHelper] JNDI InitialContext properties:{}
2006-12-29 12:13:35,639 INFO [STDOUT] Exception in thread "Queue1"
2006-12-29 12:13:35,639 INFO [STDOUT] java.lang.ExceptionInInitializerError
2006-12-29 12:13:35,641 INFO [STDOUT] at
xxx.AgentMQThread.onMessage(AgentMQThread.java:184)
2006-12-29 12:13:35,642 INFO [STDOUT] at xxx.AgentMQThread.run(AgentMQThread.java:67)
2006-12-29 12:13:35,643 INFO [STDOUT] Caused by:
java.util.ConcurrentModificationException
2006-12-29 12:13:35,643 INFO [STDOUT] at
java.util.TreeMap$PrivateEntryIterator.nextEntry(TreeMap.java:1031)
2006-12-29 12:13:35,644 INFO [STDOUT] at
java.util.TreeMap$KeyIterator.next(TreeMap.java:1058)
2006-12-29 12:13:35,644 INFO [STDOUT] at
org.jboss.mx.loading.LoadMgr3.beginLoadTask(LoadMgr3.java:221)
2006-12-29 12:13:35,645 INFO [STDOUT] at
org.jboss.mx.loading.RepositoryClassLoader.loadClassImpl(RepositoryClassLoader.java:475)
2006-12-29 12:13:35,645 INFO [STDOUT] at
org.jboss.mx.loading.RepositoryClassLoader.loadClass(RepositoryClassLoader.java:377)
2006-12-29 12:13:35,645 INFO [STDOUT] at
java.lang.ClassLoader.loadClass(ClassLoader.java:251)
2006-12-29 12:13:35,646 INFO [STDOUT] at
java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
ConcurrentModificationException in UnifiedLoaderRepository3
-----------------------------------------------------------
Key: JBJMX-45
URL: http://jira.jboss.com/jira/browse/JBJMX-45
Project: JBoss JMX
Issue Type: Bug
Reporter: SourceForge User
Assigned To: Scott M Stark
SourceForge Submitter: stottos .
The getResourceFromRepository method in
UnifiedLoaderRepository3 does not synchronize access to
the packagesMap and classLoaders fields, unlike all
other accesses to those fields. As a result, if
classes are being loaded at the same time as a resource
is being looked up, a ConcurrentModificationException
can be triggered.
I have attached a proposed patch for this bug. The fix
wraps the uses of packagesMap and classLoaders fields
in the appropriate synchronized blocks. If the all of
the class loaders need to be searched, a copy of the
classLoaders field is made to avoid having to
synchronize while performing the search. The existing
code is inconsistent in the way it makes a copy of the
classLoaders field: new HashSet(classLoaders) versus
classLoaders.clone(). I arbitrarily chose the former,
but whoever fixes the bug might consider making the
code consistent one way or the other.
I suspect that there is a second order synchronization
problem in the processing of any HashSet retrieved from
the packagesMap. The retrieved HashSet may be
concurrently modified if a class loader is added or
removed while the set is being processed. The
modifications to the HashSet's in the packagesMap
performed in the add/remove class loader code path are
performed while holding the packagesMap lock, but the
code in getResourceFromRepository and
LoadMgr3.beginLoadTask, which retrieves a package set
using the getPackageClassLoaders method, is
unsynchronized. Unless there is some other lock that
makes this a non-issue, I suspect that fixing the
problem will require either making a copy of the
HashSet or a moderate amount of code restructuring.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira