[jboss-jira] [JBoss JIRA] Updated: (JBRULES-2346) insert: ConcurrentModificationException on iterate of ObjectTypeConfigurationRegistry#typeConfMap.
[
https://jira.jboss.org/browse/JBRULES-2346?page=com.atlassian.jira.plugin...
]
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