[rules-dev] ConcurrentModificationException thrown from EntryPointNode.updateSink

Edson Tirelli ed.tirelli at gmail.com
Wed Nov 11 10:22:47 EST 2009


   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 at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>


-- 
 Edson Tirelli
 JBoss Drools Core Development
 JBoss by Red Hat @ www.jboss.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20091111/d92b7b73/attachment.html 


More information about the rules-dev mailing list