9:22 a.m.
Hi Tom,
I don't think the nested call is the problem, because it is a call to a
specific node downstream. I am thinking it could be due to the fact that a
thread could be inserting data into the same or another entry point
concurrently that is causing a side effect (although they should be
isolated).
Would you please open a JIRA for this and let me know? I will take a
careful look into this.
Thanks
Edson
2009/11/10 <Tom.E.Murphy(a)wellsfargo.com>
Using Drools 5.0.1 FINAL
Our logs contain the following exception:
java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:2117)
at java.util.HashMap$ValueIterator.next(HashMap.java:2147)
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.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:788)
at
org.drools.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:216)
at
com.wellsfargo.ARGenT.Execution.SimXmlDataLoader.Load(SimXmlDataLoader.java:713)
The code fragment around line 285 of EntryPointNode.java is the following:
Could the nested call to assertObject be causing the
ConcurrentModificationException?
In other words, could the call to sink.assertObject cause an eventual
recursive entry into updateSink or call another method that changes the
registry and effectively invalidates the objectTypeConf iterator?
public void updateSink(final ObjectSink sink,
final PropagationContext context,
final InternalWorkingMemory workingMemory) {
// @todo
// JBRULES-612: the cache MUST be invalidated when a new node type
is added to the network, so iterate and reset all caches.
final ObjectTypeNode node = (ObjectTypeNode) sink;
final ObjectType newObjectType = node.getObjectType();
InternalWorkingMemoryEntryPoint wmEntryPoint =
(InternalWorkingMemoryEntryPoint) workingMemory.getWorkingMemoryEntryPoint(
this.entryPoint.getEntryPointId() );
LINE 285: for ( ObjectTypeConf objectTypeConf :
wmEntryPoint.getObjectTypeConfigurationRegistry().values() ) {
if ( newObjectType.isAssignableFrom(
objectTypeConf.getConcreteObjectTypeNode().getObjectType() ) ) {
objectTypeConf.resetCache();
ObjectTypeNode sourceNode =
objectTypeConf.getConcreteObjectTypeNode();
Iterator it = ((ObjectHashSet) workingMemory.getNodeMemory(
sourceNode )).iterator();
for ( ObjectEntry entry = (ObjectEntry) it.next(); entry !=
null; entry = (ObjectEntry) it.next() ) {
sink.assertObject( (InternalFactHandle)
entry.getValue(),
context,
workingMemory );
}
}
}
}
*Tom Murphy
**Business Process Consultant
Wells Fargo HCFG - CORE Deal Decisioning Platform
800 S. Jordan Creek Parkway | West Des Moines, IA 50266
MAC: **X2301-01B
**Office: **515 324 4853** | Mobile: 941 320 8014
**This message may contain confidential and/or privileged information. If
you are not the addressee or authorized to receive this for the addressee,
you must not use, copy, disclose, or take any action based on this message
or any information herein. If you have received this message in error,
please advise the sender immediately by reply e-mail and delete this
message. Thank you for your cooperation.*
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
--
Edson Tirelli
JBoss Drools Core Development
JBoss by Red Hat @ www.jboss.com