[jboss-jira] [JBoss JIRA] Updated: (JBRULES-2346) insert: ConcurrentModificationException on iterate of ObjectTypeConfigurationRegistry#typeConfMap.

[Andreas Kohn (JIRA)]

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

Andreas Kohn updated JBRULES-2346:
----------------------------------

    Attachment: JBRULES-2346.diff


Using ConcurrentHashMap avoids the CME when iterating, but one still can get interesting situations if the update of the maps races: two threads may create an object, and then put it into the map. This could lead to the two threads each assuming that the next call will return the object they got earlier, but in fact one thread may have won the race, and the object put in by the first thread is lost.

For this reason I extended the patch from Toshiya Kobayashi a bit to use ConcurrentMap's #putIfAbsent() if possible.

> insert: ConcurrentModificationException on iterate of ObjectTypeConfigurationRegistry#typeConfMap.
> --------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-2346
>                 URL: https://jira.jboss.org/browse/JBRULES-2346
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Olexandr Demura
>            Assignee: Mark Proctor
>         Attachments: ClassFieldAccessorCache.java, EntryPointNode.java, JBRULES-2346.diff, JBRULES-2346.patch, ObjectTypeConfigurationRegistry.java
>
>
> Very rare exception occurs in multi-threaded environment, each thread processes series of rule evaluations with recreation of StatefulSession after each:
> java.util.ConcurrentModificationException
> 	at java.util.HashMap$HashIterator.nextEntry(HashMap.java:1091)
> 	at java.util.HashMap$ValueIterator.next(HashMap.java:1122)
> 	at org.drools.reteoo.EntryPointNode.updateSink(EntryPointNode.java:285)
> 	at org.drools.reteoo.ObjectTypeNode.attach(ObjectTypeNode.java:279)
> 	at org.drools.reteoo.builder.PatternBuilder.attachObjectTypeNode(PatternBuilder.java:234)
> 	at org.drools.reteoo.ClassObjectTypeConf.<init>(ClassObjectTypeConf.java:93)
> 	at org.drools.common.ObjectTypeConfigurationRegistry.getObjectTypeConf(ObjectTypeConfigurationRegistry.java:58)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:849)
> 	at org.drools.base.DefaultKnowledgeHelper.insert(DefaultKnowledgeHelper.java:114)
> 	at org.drools.base.DefaultKnowledgeHelper.insert(DefaultKnowledgeHelper.java:108)
> Problem is caused by cyclic dependency.
> ObjectTypeConfigurationRegistry#getObjectTypeConf(EntryPoint, Object)
> creates ClassObjectTypeConf to put into ObjectTypeConfigurationRegistry#typeConfMap,
> creation code relies on EntryPointNode#updateSink(ObjectSink, PropagationContext, InternalWorkingMemory),
> which iterates on ObjectTypeConfigurationRegistry#typeConfMap.
> I can't reproduce it on 5.1.0.M1 now, but because of rare reproduction.
> Source looks like have this bug yet. 
> Used workaround for it:
> EntryPointNode#updateSink(ObjectSink, PropagationContext, InternalWorkingMemory) iterates on copy of ObjectTypeConfigurationRegistry#typeConfMap:
>         for ( ObjectTypeConf objectTypeConf : wmEntryPoint.getObjectTypeConfigurationRegistry().values() ) {
> ->
>         for ( ObjectTypeConf objectTypeConf : new ArrayList<ObjectTypeConf>(
>                 new wmEntryPoint.getObjectTypeConfigurationRegistry().values() )) {

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