Thanks for the feedback!

   Edson

2010/7/29 dmiller44 <dmiller@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@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@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@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users



--
  Edson Tirelli
  JBoss Drools Core Development
  JBoss by Red Hat @ www.jboss.com