[rules-users] Possible "memory leak" in 5.3 with update?

Wolfgang Laun wolfgang.laun at gmail.com
Sun Apr 1 15:42:04 EDT 2012


Did you compare the described scenario to one where you don't insert
and update facts but just store and replace objects in a Map: key -> object?
-W


On 01/04/2012, thenim <thenim at gmail.com> wrote:
> I'm using a stateful session (in a slightly odd way - obviously this is the
> problem), I have a stream of "messages" coming into my system and each
> message one of a set of unique keys. Now my rules test various attibutes of
> this message and makes some changes (to the messages) etc. (the rules aren't
> the problem here - infact in my test case, I have no rules).
>
> I tested the "normal" approach where each message is inserted and the fact
> handle retained, and subsequently after firing, the handle is removed (yes
> this sounds like a good case for Fusion, except for the making changes bit.)
> I noticed that I could get better throughput, if took the following
> approach:
>
> 1. On the first time the unique key is detected, the handle is saved
> 2. Then each time a message with that key is received, "update" is called
> with the handle for that key
>
> Now, the important thing here is that the "fact" is a *different* object not
> an updated version of the original associated with the handle.
>
> Now with this approach, I was getting better numbers, however every so often
> there would be a "pause", with GC details being printed out, I see
> immediately that it's sitting there doing full GC's very frequently, and
> switching to the concurrent collector, I can see mode failures regularly
> (i.e. full GCs). With a low message rate, I didn't notice it initially, but
> with higher message rates, this is a serious issue.
>
> It appears that the approach I've taken highlights a "leak". I wanted to
> find out if others have encountered this before digging around in the code,
> for the moment, I will "fix" my approach so that I update the "same object"
> - but is "update" not meant to be used this way?
>
> Thanks,
> Nim
>
> --
> View this message in context:
> http://drools.46999.n3.nabble.com/Possible-memory-leak-in-5-3-with-update-tp3874271p3874271.html
> Sent from the Drools: User forum mailing list archive at Nabble.com.
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>



More information about the rules-users mailing list