[ https://issues.jboss.org/browse/JBRULES-3385?page=com.atlassian.jira.plug... ] Manuel Reinaldo Falagan commented on JBRULES-3385: -------------------------------------------------- I have been debuging the problem and I found that in the method updateSink from JoinNode, the loop "for ( LeftTuple leftTuple = (LeftTuple) tupleIter.next(); leftTuple != null; leftTuple = (LeftTuple) tupleIter.next() )" does loop over one object less in the case that it fails. I don't know yet if the iterator is working wrong of if the data is not in the list. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBRULES-3385?page=com.atlassian.jira.plug... ] Manuel Reinaldo Falagan edited comment on JBRULES-3385 at 2/15/12 9:15 AM: --------------------------------------------------------------------------- The data is arranged differently in the case that it works and in the case that it doesn't (within the itereator) but both seam ok. When it works, the FieldIndexHashTableFullIterator.table, has a reference to all the tuples, but when it doesn’t, it has a reference to all except one. This one is linked to another tuple in the table which if I understand the code properly, it is correct. was (Author: manuelreinaldo): Further investigation shows that the problem is in the data in the iterator. The FieldIndexHashTable$FullIterator used for the loop has one tuple less in the case that it fails. I have put a breakpoint in the method LeftTupleIndexHashTable.getOrCreate() and this method is called for all the tuples in both cases, the one that works and the one which doesn't, but somewhere in between this and the creation of the iterator one tuple is lost. In fact, in the debuggin, the data in the AbstractHashTable is correct in both cases until the iterator is created. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBRULES-3385?page=com.atlassian.jira.plug... ] Manuel Reinaldo Falagan edited comment on JBRULES-3385 at 2/16/12 5:17 AM: --------------------------------------------------------------------------- I found the problem. When the table in LeftTupleIndexHashTable has a bucket with more than one tuple in the last position (in my case position 127), only the first tuple is returned so the iterator goes through one less case. The method next() in LeftTupleIndexHashTable sets the row to 128 (greater than the lenght) in the retrieval the first tuple of in the bucket 127 and following tuples are not retrieved. I don't know the solution or why the order in loading the classes affects this (may be because the hashtables change). Is there any DROOLS expert who can take a look? was (Author: manuelreinaldo): I found the problem. When the table in LeftTupleIndexHashTable has a bucket with more than one tuple in the las position (in my case position 127), only the first tuple is returned so the iterator goes through one less case. The method next() in LeftTupleIndexHashTable sets the row to 128 (greater than the lenght) in the retrieval the first tuple of in the bucket 127 and following tuples are not retrieved. I don't know the solution or why the order in loading the classes affects this (may be because the hashtables change). Is there any DROOLS expert who can take a look? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBRULES-3385?page=com.atlassian.jira.plug... ] Manuel Reinaldo Falagan commented on JBRULES-3385: -------------------------------------------------- I have a possible patch: In file LeftTupleIndexHashTable.java at line 249 (of 5.3.0_Final) replace line: while ( this.row < this.length ) { with: while ( this.row < this.length || this.list!=null) { The same change I think it has to be made in the RightTupleIndexHashTable.java -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBRULES-3385?page=com.atlassian.jira.plug... ] Manuel Reinaldo Falagan updated JBRULES-3385: --------------------------------------------- Attachment: LeftTupleIndexHashTable.java RightTupleIndexHashTable.java -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBRULES-3385?page=com.atlassian.jira.plug... ] Manuel Reinaldo Falagan updated JBRULES-3385: --------------------------------------------- Description: A very simple example "FailTest" triggers a rule only 15 times when it should trigger it 16 times. The same example with almost any change to the class model or to the order in loading the classes or the input data or the version of java it works. The Class FailTest contains only a main method calling the main method of the Class HelloWorldExample. Running directly the main method in the class HelloWorldExample does work. Any change fixes the problem in the example but it moves the error to other part. We have set a test testing more than 2000 million cases of rules/inputs and no matter how we write the rules or the code, we end up finding a case that fails, making the software not usable, as it is not predictable were it is going to fail. The case has been uner study for more than a year and we have tried AIX, Linux and XP with DROOLS 5.1, 5.2, 5.3 and the trial of Enterprise edition. The example provided has only been tested to fail for DROOLS 5.3.0 final and Enterprise edition for SLES11 SP1 with the SUN virtual machine (not the IBM one) and for XP but there is no combination for which DROOLS work for the 2000 million cases. The example provided is a 7kb example self-contained ( attached file DROOLS_ERROR.zip ) was: A very simple example "FailTest" triggers a rule only 15 times when it should trigger it 16 times. The same example with almost any change to the class model or to the order in loading the classes or the input data or the version of java it works. The Class FailTest contains only a main method calling the main method of the Class HelloWorldExample. Running directly the main method in the class HelloWorldExample does work. Any change fixes the problem in the example but it moves the error to other part. We have set a test testing more than 2000 million cases of rules/inputs and no matter how we write the rules or the code, we end up finding a case that fails, making the software not usable, as it is not predictable were it is going to fail. The case has been uner study for more than a year and we have tried AIX, Linux and XP with DROOLS 5.1, 5.2, 5.3 and the trial of Enterprise edition. The example provided has only been tested to fail for DROOLS 5.3.0 final and Enterprise edition for SLES11 SP1 with the SUN virtual machine (not the IBM one) and for XP but there is no combination for which DROOLS work for the 2000 million cases. The example provided is a 7kb example self-contained ( ftp://mpf:mpf@ftp.eumetsat.int/DROOLS_ERROR.zip ) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira