Thanks for the feedback! Edson
2010/7/29 dmiller44 <[email protected]> > > 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 <[email protected]> > > > >> > >> 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 > >> [email protected] > >> 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 > > [email protected] > > 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 > [email protected] > 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 [email protected] https://lists.jboss.org/mailman/listinfo/rules-users
