10:41 a.m.
[
https://issues.jboss.org/browse/JBRULES-2810?page=com.atlassian.jira.plug...
]
Edson Tirelli commented on JBRULES-2810:
----------------------------------------
Tom,
As discussed previously, I am attaching to this ticket an instrumented drools-core jar to
help us track down the problem. Can you please replace the drools-core-XXX.jar in your
test application by this one and send us the results for analysis? If your test case deals
with sensitive data, please send the results to my corporate e-mail, otherwise, just
attach them to this ticket.
To generate the report:
1. replace the drools-core-xxx.jar by the attached jar.
2. optionally set the system property: drools.dump.file with the path/filename of the file
where the report will be appended (TXT file). Example:
java -Ddrools.dump.file=/tmp/jbrules-2810.txt ...
If the property is not set, drools will try to generate a file named
"session-999.report.txt", where 999 is replaced by the session ID for which the
report was generated. The file will be generated in the current directory. If the
application does not have write permissions to the target directory, it will raise an IO
exception and will dump the stack trace and report to the console.
3. ideally, it would be good if you can also configure the WorkingMemoryFileLogger to
generate the audit log for us to analyze and pair it with the above report. Please note
that if your test case is large, the audit log can be huge. If that is the case, lets work
with the above report first and if necessary we figure out a strategy to work with the
audit log.
4. Run the test and after a NPE is raised on the RightInputAdapterNode, a report should be
generated as described above. Stop the test and send us the report and the audit log (if
it was active).
Thanks,
Edson
NullPointerException in Drools 5.1.1 - retractLeftTuple()
---------------------------------------------------------
Key: JBRULES-2810
URL: https://issues.jboss.org/browse/JBRULES-2810
Project: Drools
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: drools-core
Affects Versions: 5.1.1.FINAL
Environment: WIndows Server 2K3 (32-bit) - JBoss 5 AS, Drools 5.1.1 Final,
Reporter: Tom Murphy
Assignee: Mark Proctor
We recently switched to Drools 5.1.1 in our testing environments, and we are seeing a
NullPointerException on a number of rule base / test case combinations. These all worked
fine in 5.0.1.
The rule in question is relatively simple, but the rule base is complex.
It's difficult to send a test case, because the exception appears to occur only in
large rule bases and layered rule flows.
We have had to roll back to Drools 5.0.1 and are unable to adopt 5.1.1 until this is
resolved.
The relevant stack trace info is below.
com.wellsfargo.ARGenT.Execution.ARGenTRunTimeException -
org.drools.runtime.rule.ConsequenceException: rule: RS7673.1.3_RF6365_83_50011728
...
Caused by:
rule: RS7673.1.3_RF6365_83_50011728
at
org.drools.runtime.rule.impl.DefaultConsequenceExceptionHandler.handleException(DefaultConsequenceExceptionHandler.java:39)
at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:927)
at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:856)
at org.drools.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1071)
at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:785)
at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:751)
at
org.drools.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:218)
...
Caused by:
null
at
org.drools.reteoo.RightInputAdapterNode.retractLeftTuple(RightInputAdapterNode.java:154)
at
org.drools.reteoo.SingleLeftTupleSinkAdapter.doPropagateRetractLeftTuple(SingleLeftTupleSinkAdapter.java:217)
at
org.drools.reteoo.SingleLeftTupleSinkAdapter.propagateRetractRightTuple(SingleLeftTupleSinkAdapter.java:124)
at org.drools.reteoo.JoinNode.retractRightTuple(JoinNode.java:151)
at org.drools.reteoo.ModifyPreviousTuples.retractTuples(ModifyPreviousTuples.java:132)
at org.drools.reteoo.EntryPointNode.modifyObject(EntryPointNode.java:176)
at org.drools.common.AbstractWorkingMemory.update(AbstractWorkingMemory.java:1442)
at org.drools.common.AbstractWorkingMemory.update(AbstractWorkingMemory.java:1349)
at org.drools.base.DefaultKnowledgeHelper.update(DefaultKnowledgeHelper.java:183)
at org.drools.base.DefaultKnowledgeHelper.update(DefaultKnowledgeHelper.java:196)
at
com.wellsfargo.GeneratedRules.Rule_RS7673_1_3_RF6365_83_50011728_0.defaultConsequence(Rule_RS7673_1_3_RF6365_83_50011728_0.java:9)
at
com.wellsfargo.GeneratedRules.Rule_RS7673_1_3_RF6365_83_50011728_0DefaultConsequenceInvoker.evaluate(Rule_RS7673_1_3_RF6365_83_50011728_0DefaultConsequenceInvoker.java:29)
at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:917)
at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:856)
at org.drools.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1071)
at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:785)
at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:751)
at
org.drools.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:218)
...
The line identified in in the exception from retractLeftTuple is in the for loop, and it
references factHandle without first checking for null:
// retrieve handle from memory
final InternalFactHandle factHandle = (InternalFactHandle) memory.remove( tuple
);
>>>>>> for ( RightTuple rightTuple = factHandle.getFirstRightTuple();
rightTuple != null; rightTuple = (RightTuple) rightTuple.getHandleNext() ) {
rightTuple.getRightTupleSink().retractRightTuple( rightTuple,
context,
workingMemory );
}
factHandle.setFirstRightTuple( null );
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira