[ http://jira.jboss.com/jira/browse/JBRULES-904?page=all ] Edson Tirelli reassigned JBRULES-904: ------------------------------------- Assignee: Edson Tirelli (was: Mark Proctor) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBRULES-904?page=comments#action_12366415 ] Dirk Bergstrom commented on JBRULES-904: ---------------------------------------- Ignore the testcase.tar.gz attachement I just uploaded. That was supposed to go on JBRULES-909. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBRULES-904?page=comments#action_12366927 ] Brian Stiles commented on JBRULES-904: -------------------------------------- I think I'm either wrong in my assumptions or org.drools.util.TupleIndexHashTable is more broken than I originally thought. My assumption is that there should be a one to one correspondence of TupleIndexHashTable.FieldIndexEntry objects to ReteTuples and that the FieldIndexEntry's first and next should correspond to the corresponding ReteTuple and it's next. That's what I assume org.drools.util.TupleIndexHashTable.FieldIndexEntry.add(ReteTuple) tries to make true. With my above patch, my assumption holds true until org.drools.util.AbstractHashTable.resize(int) is called. resize fixes up the relationships of the FieldIndexEntrys but not the ReteTuples. I don't know about remove, yet. If I disable the call to resize, I don't get the ArrayIndexOutOfBoundsException and things seem to work fine. Can anyone confirm or deny my assumptions? If my assumptions are wrong, I need to rethink (or be told) how the table is supposed to work and my previous comments should probably be disregarded. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBRULES-904?page=comments#action_12366940 ] Brian Stiles commented on JBRULES-904: -------------------------------------- Well, I can't confirm that the toArray problem is fixed because after backing out my changes and applying yours, I'm back to the problem that originally led me here. I think I may have run into the ArrayIndexOutOfBoundsException when I was investigating this problem (having made some experimental changes). It may be that I'm confusing two different problems, but I suspect they're related. After applying your changes, I now get the following exception (which I was getting originally): Exception in thread "main" java.lang.NullPointerException at org.drools.rule.VariableRestriction.isAllowedCachedRight(VariableRestriction.java:79) at org.drools.rule.VariableConstraint.isAllowedCachedRight(VariableConstraint.java:78) at org.drools.common.DoubleBetaConstraints.isAllowedCachedRight(DoubleBetaConstraints.java:149) at org.drools.reteoo.CollectNode.assertObject(CollectNode.java:220) at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:317) at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:159) at org.drools.reteoo.Rete.assertObject(Rete.java:175) at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:190) at org.drools.reteoo.ReteooWorkingMemory.doInsert(ReteooWorkingMemory.java:70) at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:772) The cause of the above exception is the fact that org.drools.util.TupleIndexHashTable.toArray produces an array with nulls in it. I assumed that this was probably related to the ArrayIndexOutOfBoundException, but it may be a separate problem. I'd be happy to open a new bug if appropriate. The nulls in the array, I believe, come from the first/next mismatch described above. Are the assumptions in my prior post valid? What other information can I give you? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBRULES-904?page=comments#action_12366943 ] Brian Stiles commented on JBRULES-904: -------------------------------------- I have nothing to do with the attached test cases, so I don't know if they'll recreate the problem I'm describing. Are the assumptions I described correct? If so, I'll see if I can put together a test case. If not, I'll keep investigating. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBRULES-904?page=comments#action_12366950 ] Mark Proctor commented on JBRULES-904: -------------------------------------- took me a while to remove all the threading from the system and DataSource stuff. so it all ran in one method :) But once that was done I inserted the minimal information to make it occur. Once I saw why it was happening, it was quick to fix, it wasn't iterating the parent and child linkedlists in the toArray. So there was two bugs for this bug, but this should hopefully be fixed now :) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBRULES-904?page=comments#action_12366952 ] Brian Stiles commented on JBRULES-904: -------------------------------------- As far as I can tell, your fix solves the problem. I'm a bit concerned that there might be other problems lurking, though, since I believe that there are some broken assumptions in the code. Perhaps the code as is will operate sufficiently, and if so, fine, but I think there are some issues worth looking at. Looks to me like TupleIndexHashTable must have been cut-n-paste-modified from TupleHashTable. TupleHashTable uses ReteTuples as its entries but TupleIndexHashTable uses FieldIndexEntry as entries that hold Tuples. If my overall assessment is correct, there has been an incomplete shift from using ReteTuples (Entry/Tuple chimeras) as entries to FieldIndexEntrys (that hold references to Tuples) as entries. (On a more general note, I think that the interface defined by org.drools.reteoo.TupleMemory adds to the problem here since it limits implementation choices by using ReteTuple instead of Tuple, thereby requiring the tuple also to implement org.drools.util.Entry.) Look at the inner while loop in toArray in your code. I don't believe that "entry.getNext()" can ever return non-null because entry is the ReteTuple (should just be Tuple) held by fieldIndexEntry and the tuple's "next" is never set with a non-null value (and shouldn't be because the FieldIndexEntry is being used as the table entry, not the tuple). This has held true in my testing. Similarly, look at getOrCreate. If "entry.matches(tuple, hashCode)" in the while loop ever was true, there would be a mismatch between tuples and FieldIndexEntrys (more tuples than entries). I'm not certain this would be a problem, but it looks to me like that breaks FieldIndexHashTableIterator.next. And, it looks like FieldIndexHashTableFullIterator.next can't work properly since the following line this.entry = (this.table[this.row] != null) ? ((FieldIndexEntry) this.table[this.row]).first : null; sets "this.entry" to a ReteTuple which will never have "next" that is a FieldIndexEntry. I never saw either "next" called in my testing, so I can't confirm whether or not the work as is. I'm going to add an attachment with a patch for org.drools.util.TupleIndexHashTable that cleans things up according to my assumptions. If you think it's worth looking at, you can check out what I've done and see if it makes sense. I am not sure if the iterator classes are supposed to iterate over FieldIndexEntrys or ReteTuples, but my code assumes FieldIndexEntrys. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBRULES-904?page=comments#action_12366956 ] Dirk Bergstrom commented on JBRULES-904: ---------------------------------------- Sorry about the complexity of the testcase -- I reused the code for an earlier case. If you want to mail me the version you made, I'll keep it around in case I've got more use for it. I think the bug is fixed, but I can't be sure, because I'm getting hit with JBRULES-909 on almost all of my rules and classes, including the ones that used to trigger this bug. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira