[jboss-jira] [JBoss JIRA] (JBRULES-3617) NullpointerException in Accumulate when use query

[ https://issues.jboss.org/browse/JBRULES-3617?page=com.atlassian.jira.plug... ] Mario Fusco commented on JBRULES-3617: -------------------------------------- The problem arises when you try to concurrently modify a rulebase while another thread is already using the knowledge session. Originally I thought the problem was caused by a race condition, but this is not the case. Edson suggested that it could have been caused by the shared alpha node or anyway by the Rete network being not correctly created, but also this is not completely correct. So let me explain step by step what happens in reality: 1. A new package is added to the knowledge base. That triggers a modification of the rulebase and then a write lock is acquired on it. At the end of this process the Rete network will look as it follows: [EntryPointNode(1) EntryPoint::DEFAULT ] [ObjectTypeNode(2)::EntryPoint::DEFAULT objectType=[ClassObjectType class=org.drools.integrationtests.JbRules3617$Person] expiration=-1ms ] [AlphaNode(7) constraint=firstname == "Tom"] [AlphaNode(11) constraint=secondname == "Cat"] [ AccumulateNode(12) ] [RuleTerminalNode(14): rule=test] [JoinNode(8) - [ClassObjectType class=org.drools.integrationtests.JbRules3617$Person]] [QueryTerminalNode(9): query=find] 2. In the meanwhile the other thread is trying to update a fact. Since the main thread is modifying the rulebase it will wait acquiring a read lock on it (NamedEntryPoint#389). 3. The Rete builder creates the JoinNode and when it gets attached to the Rete it propagates a sink update on the Alpha and on the ObjectType nodes. This last one triggers an assertObject of the (only one) fact handle in its memory. Since the fact satisfies the constraint of the alpha node (the Person's name is "Tom") the assertObject is propagated to the JoinNode that creates a new RightTuple. This RightTuple (having the JoinNode as sink) is added to the FactHandle itself. 4. The Rete builder creates the AccumulateNode. Following exactly the same path of the former point, when it gets attached to the Rete, a second RightTuple (having the AccumulateNode as sink) is added to the FactHandle. Moreover, the same FactHandle is also accumulated by the AccumulateNode. I am reporting below the source code of the generated accumulator because it will be useful to better explain what happens in the following steps: public class Accumulate0 implements java.io.Serializable { private java.util.Map reverseMap = new java.util.HashMap<Integer, ReverseSnapshot>(); private HashSet set; public Accumulate0() { } public void init() throws Exception { set = new HashSet(); } public void accumulate(org.drools.WorkingMemory workingMemory, org.drools.common.InternalFactHandle handle, org.drools.rule.Declaration[] innerDeclarations, Object object, java.lang.String $addr) throws Exception { this.reverseMap.put( Integer.valueOf( handle.getId() ), new ReverseSnapshot( $addr ) ); set.add($addr); } public void reverse(org.drools.WorkingMemory workingMemory, org.drools.common.InternalFactHandle handle, Object object ) throws Exception { ReverseSnapshot snapshot = (ReverseSnapshot) this.reverseMap.remove( Integer.valueOf( handle.getId() ) ); java.lang.String $addr = snapshot.$addr; set.remove($addr); } public Object getResult( ) throws Exception { return ( set ); } public boolean supportsReverse() { return true; } private static class ReverseSnapshot implements java.io.Serializable { public final java.lang.String $addr; public ReverseSnapshot( final java.lang.String $addr ) { this.$addr = $addr; } } } 5. The building process of the Rete network is finished so the main thread has released the write lock on it. The concurrent one can finally acquire the read lock and go forward with the fact update. In the EntryPointNode.modifyObject method a new ModifyPreviousTuples is created (EntryPointNode#260) and here it comes my first doubt: for what said in the former steps the FactHandle now has 2 RightTuples, one having the JoinNode as sink and the other having the AccumulateNode, but for some reason only the first one is carried in the ModifyPreviousTuples object. Is this (always) correct? 6. The object modification hits the AccumulateNode. Here (BetaNode#520) the RightTupleSink in the ModifyPreviousTuples (the JoinNode) is different from the current node (the AccumulateNode), or more in details their rightInputOtnIds are different. This is the main cause of the bug because, for this reason, the RightTuple is NOT removed from the ModifyPreviousTuples and the FactHandle is asserted (again) on the AccumulateNode. It means that the accumulate method of the Accumulator (see code above) is called again with the same FactHandle and a new ReverseSnapshot replaces the existing in the reverseMap. 7. At the end of the EntryPointNode.modifyObject method (EntryPointNode#301), since the ModifyPreviousTuples still has a RightTuple having the AccumulateNode as sink, the AccumulateNode itself retracts the FactHandle by invoking the reverse method of its Accumulator. Here the ReverseSnapshot corresponding to the (only) accumulated fact is removed leaving the reverseMap empty. 8. The infinite loop in the concurrent thread tries to update the same FactHandle again. This time the Rete network isn't changed so the update is correctly propagated calling the modifyRightTuple method of the AccumulateNode. Here the AccumulateNode tries to remove the FactHandle from the Accumulator before to add it again, but when it invokes the reverse method the reverseMap is empty, so the ReverseSnapshot is null and the subsequent statement throws the NPE reported in the jira ticket. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira