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

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.