[jboss-jira] [JBoss JIRA] Created: (JBRULES-2225) Locking in CompositeClassLoader is broken

[Andreas Kohn (JIRA)]

Locking in CompositeClassLoader is broken
-----------------------------------------

                 Key: JBRULES-2225
                 URL: https://jira.jboss.org/jira/browse/JBRULES-2225
             Project: JBoss Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-core
    Affects Versions: 5.0.1.FINAL
         Environment: Fedora 11 Linux (kernel 2.6.29.6-213.fc11.x86_64), OpenJDK 64-Bit Server VM (build 16.0-b07, mixed mode)

            Reporter: Andreas Kohn
            Assignee: Mark Proctor
         Attachments: drools.patch

CompositeClassLoader appeared in some of my application profile runs as source of lock contention. 

Looking at the class it seems the locking is actually broken: the modification methods are not using any locking, but assume that the classLoader list is not modified, and all loadClass() is synchronized, but that synchronized just serves as contention point, but doesn't actually protect against ConcurrentModificationExceptions (as the modifiers are unsynchronized).

Attached patch against CompositeClassLoader (from http://anonsvn.labs.jboss.com/repos/labs/labs/jbossrules/branches/5.0.x , but code in trunk looks reasonably identical) fixes both these issues:

* class loaders are stored in copy-on-write array list, so that read accesses can avoid synchronization completely. 
* removeClassLoader() and addClassLoader() use synchronized to protect against concurrent calls to add and remove with the same classloader, as otherwise the no-duplicates assumption might get violated.

This assumes that reads are frequent, and updates are fairly rare.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira