[jboss-jira] [JBoss JIRA] Commented: (JBJMX-45) ConcurrentModificationException in UnifiedLoaderRepository3

[Steve Gibson (JIRA)]

    [ 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