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

[Edson Tirelli (JIRA)]

     [ https://jira.jboss.org/jira/browse/JBRULES-2225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli closed JBRULES-2225.
----------------------------------

    Fix Version/s: 5.1.0.M2
       Resolution: Done


Fixed. Thanks for reporting, providing test case and patch.

> Locking in CompositeClassLoader is broken
> -----------------------------------------
>
>                 Key: JBRULES-2225
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2225
>             Project: 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: Edson Tirelli
>             Fix For: 5.1.0.M2
>
>         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