[rules-users] Drools Objects not released from heap
Edson Tirelli
tirelli at post.com
Sat Jul 31 10:29:53 EDT 2010
Thanks for the feedback!
Edson
2010/7/29 dmiller44 <dmiller at versatile.com>
>
> Edson,
>
> Sorry - we just solved this. The leak isn't in Drools (which I suspected
> it
> might not be) but was in fact with java.util.concurrent.
> LinkedBlockingQueue. We were running JDK 6 Update 16 - which apparently
> suffers from the issue described in this ticket:
>
> http://bugs.sun.com/bugdatabase/view_bug.do;jsessionid=468c6d6197d54781dd3fb3bb3dc4c?bug_id=6806875
> Bug ID 6806875
>
> Once upgrading the JDK to Update 20, the problem went away. Now we're
> seeing the performance from Drools that we have had prior to this issue :)
>
> Sorry to trouble all of you with this - hopefully if someone has similar
> issues, the JDK upgrade will solve it for them as well.
>
> Dan
>
>
> Edson Tirelli-3 wrote:
> >
> > Dan,
> >
> > I am not aware of any memory leak in CR1. If you can provide me
> with
> > a
> > test case I will investigate this today. Please open a JIRA, attach your
> > test case and let me know. If there is a leak, I need to fix it before
> > final
> > release.
> >
> > And it is not a problem to instantiate objects in a rule's
> > consequence.
> > That is "business as usual".
> >
> > Thanks,
> > Edson
> >
> > 2010/7/28 dmiller44 <dmiller at versatile.com>
> >
> >>
> >> Hello,
> >>
> >> I have a weird issue, and I'm trying to figure out if this is a bug I
> >> should
> >> report, or an error in my rule. I'm running an application with a heap
> >> space (min: 512mb, max: 1024mb) that gets full and eventually overflows
> >> relatively quickly (12hrs or less). We insert about 112 records into a
> >> Stateful Drools Session (Drools 5.1 CR1 released 7/22/2010) every
> >> 30seconds,
> >> using CLOUD session type, single thread, with fireUntilHalt.
> >>
> >> Our rules evaluate the object (A) we give it, and in some cases
> >> instantiate
> >> a new object (B) and insert it into the session. After processing
> object
> >> (A), we retract it from the session.
> >>
> >> Another rule matches on object (B), and when finished, also retracts the
> >> object.
> >>
> >> When I do a heap snapshot, I've noticed quite a few Drools-related
> >> classes,
> >> along with unreleased instantiations of object(A) & object(B) (more of
> >> the
> >> latter). Obviously I have to take into consideration that objects are
> >> being
> >> inserted at the time of the snapshot, but over a couple hours I'll have
> >> 1000's of these objects. I've found the only fix to be to release the
> >> session.
> >>
> >> I should note - calling session.getObjects() shows an empty list (size
> >> 0).
> >>
> >> Is this a bug? When retract is called, shouldn't it free up the
> >> FactHandle
> >> &
> >> Object to be collected? And is instantiating an object in a rule
> >> incorrect
> >> for some reason?
> >>
> >> Below is a small chart of classes - the number of instances - and space
> >> taken. (TemperatureEvent represents object (A), while AssetShallowRemote
> >> represents object (B)) Any input would be appreciated.
> >>
> >> Dan
> >>
> >>
> >> | Class |
> >> Instances
> >> |
> >> Size | |
> >>
> >>
> |--------------------------------------------------------------+-----------+----------+---|
> >> | java.lang.String |
> >> 1155258
> >> |
> >> 41589288 | |
> >> | char[] |
> >> 1153540
> >> |
> >> 91560120 | |
> >> | java.util.concurrent.LinkedBlockingQueue$Node |
> >> 329989
> >> |
> >> 10559648 | |
> >> | java.util.LinkedHashMap$Entry |
> >> 153489
> >> |
> >> 9209340 | |
> >> | java.util.HashMap$Entry |
> >> 151929
> >> |
> >> 6684876 | |
> >> | java.sql.Timestamp |
> >> 117017
> >> |
> >> 4212612 | |
> >> | org.drools.reteoo.LeftTuple |
> >> 53395
> >> |
> >> 8756780 | |
> >> | org.drools.common.AgendaItem |
> >> 53390
> >> |
> >> 5819510 | |
> >> | org.drools.retoo.RightTuple |
> >> 53386
> >> |
> >> 5125056 | |
> >> | my.test.package.AssetShallowRemote | 42995 | 11780630 | |
> >> | org.drools.common.DefaultFactHandle |
> >> 37273
> >> |
> >> 3280024 | |
> >> | org.drools.core.util.ObjectHashSet$ObjectEntry |
> >> 37273
> >> |
> >> 1341828 | |
> >> | org.drools.common.PropagationContextImpl |
> >> 32721
> >> |
> >> 2683512 | |
> >> | org.drools.core.util.ObjectHashMap$ObjectEntry |
> >> 32721
> >> |
> >> 1639924 | |
> >> | my.test.package.TemperatureEvent | 7165 |
> >> 917120 | |
> >>
> >> --
> >> View this message in context:
> >>
> http://drools-java-rules-engine.46999.n3.nabble.com/Drools-Objects-not-released-from-heap-tp1002541p1002541.html
> >> Sent from the Drools - User mailing list archive at Nabble.com.
> >> _______________________________________________
> >> rules-users mailing list
> >> rules-users at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/rules-users
> >>
> >
> >
> >
> > --
> > Edson Tirelli
> > JBoss Drools Core Development
> > JBoss by Red Hat @ www.jboss.com
> >
> > _______________________________________________
> > rules-users mailing list
> > rules-users at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/rules-users
> >
> >
> --
> View this message in context:
> http://drools-java-rules-engine.46999.n3.nabble.com/Drools-Objects-not-released-from-heap-tp1002541p1007840.html
> Sent from the Drools - User mailing list archive at Nabble.com.
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
--
Edson Tirelli
JBoss Drools Core Development
JBoss by Red Hat @ www.jboss.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20100731/e69bbdaf/attachment.html
More information about the rules-users
mailing list