11:09 p.m.
[ http://jira.jboss.com/jira/browse/JBRULES-740?page=all ]
Dirk Bergstrom updated JBRULES-740:
-----------------------------------
Attachment: more-stacktraces.txt
The file more-stacktraces.txt has traces taken while my app was hung trying to assert an
object.
The object being asserted is a PRRecord, #938 of 10,500. I don't know
why it hung on the 938th object; if I run it multiple times, it hangs
on different objects, and sometimes in different threads (while
asserting a different class of object). These stacktraces were taken
over a 40 minute period, during which the jvm was fully utilizing a
CPU, and no progress was made (ie. it never finished asserting the
object).
The rule that shows up in the traces is:
rule "Find all PRs for user"
when
$user : User( )
$pr_list : RecordSet( size > 0 ) from
collect( PRRecord( $resp : responsible -> ( $user.hasReport($resp) ) ) )
then
$user.setRecords($pr_list, DataSource.GNATS);
end
This is using trunk, revision 10879, with Tirelli's hashcode caching
fix. The good news is that it's not spending all its time calculating
the hashcode; the bad news is that it's still hung.
IncompatibleClassChangeError working with ShadowProxy
-----------------------------------------------------
Key: JBRULES-740
URL: http://jira.jboss.com/jira/browse/JBRULES-740
Project: JBoss Rules
Issue Type: Bug
Security Level: Public(Everyone can see)
Affects Versions: 3.1-m2
Environment: Trunk (revision 10170)
Reporter: Dirk Bergstrom
Assigned To: Edson Tirelli
Fix For: 3.1-m2
Attachments: more-stacktraces.txt, Record.java, RLIRecord.java, stacktraces.txt
I'm getting an exception while asserting objects into the working memory. Depending
on the timing, I get different stacktraces leading up the same exception on the same
generated class. I have 15 rules and three types of objects in the working memory. 2500
User objects, 37 Milestone objects, and 2000 RLI objects. If I assert all the Users and
Milestones first, I get the first exception below during assertion of the RLI objects, at
the 257th object asserted. If I arrange to skip that particular record, I can assert a
few more before another record trips the bug. If I put a try/catch block around the
assertion and continue after hitting an exception, I can assert about 1600 of the records
successfully, and the others reliably throw (ie. if I try to assert them later). If I
assert RLIs first, I get the second stacktrace during assertion of Milestones. Looks like
the problem happens during execution of one or more rules. I'll attach the RLI class,
and its parent class (which is also the parent of the other two classes).
Exception in thread "RLIs Processor" java.lang.IncompatibleClassChangeError
at net.juniper.dash.data.RLIRecordShadowProxy.hashCode(Unknown Source)
at java.util.HashMap.put(HashMap.java:418)
at java.util.HashSet.add(HashSet.java:194)
at org.drools.reteoo.CollectNode.assertTuple(CollectNode.java:135)
at org.drools.reteoo.CollectNode.assertObject(CollectNode.java:212)
at
org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:20)
at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:145)
at
org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:304)
at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:176)
at org.drools.reteoo.Rete.assertObject(Rete.java:121)
at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:196)
at
org.drools.reteoo.ReteooWorkingMemory.doAssertObject(ReteooWorkingMemory.java:68)
at
org.drools.common.AbstractWorkingMemory.assertObject(AbstractWorkingMemory.java:729)
at
org.drools.common.AbstractWorkingMemory.assertObject(AbstractWorkingMemory.java:548)
Exception in thread "Milestones and NPI Processor"
java.lang.IncompatibleClassChangeError
at net.juniper.dash.data.RLIRecordShadowProxy.hashCode(Unknown Source)
at java.util.HashMap.put(HashMap.java:418)
at java.util.HashSet.add(HashSet.java:194)
at org.drools.reteoo.CollectNode.assertTuple(CollectNode.java:135)
at
org.drools.reteoo.CompositeTupleSinkAdapter.propagateAssertTuple(CompositeTupleSinkAdapter.java:30)
at org.drools.reteoo.JoinNode.assertTuple(JoinNode.java:116)
at
org.drools.reteoo.SingleTupleSinkAdapter.createAndPropagateAssertTuple(SingleTupleSinkAdapter.java:55)
at org.drools.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:147)
at
org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:20)
at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:145)
at
org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:20)
at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:176)
at org.drools.reteoo.Rete.assertObject(Rete.java:121)
at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:196)
at org.drools.reteoo.ReteooWorkingMemory.doAssertObject(ReteooWorkingMemory.java:68)
at org.drools.common.AbstractWorkingMemory.assertObject(AbstractWorkingMemory.java:729)
at org.drools.common.AbstractWorkingMemory.assertObject(AbstractWorkingMemory.java:548)
at net.juniper.dash.data.DataSource.reconcileAssertedRecords(DataSource.java:190)
at net.juniper.dash.data.DataSource.populateRecords(DataSource.java:150)
at net.juniper.dash.Updater$DataSourceProcessor.work(Updater.java:181)
at net.juniper.dash.Refresher.run(Refresher.java:70)
--
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