[rules-users] queries in Drools 5.0

[Mark Proctor]

Quinn, Dan wrote:
> We are writing an app which has a large number of facts. This app also 
> needs to make lots of queries against working memory. Our memory 
> footprint seems to be expanding at an undesirable rate due to the 
> number of queries made against working memory. It is increasing at a 
> rate where after a couple of days the app will consume all the 
> resources on the machine. This app is stateful and needs to stay up 
> for a long duration. Rebooting it every couple of day to clean up 
> working memory would not be acceptable.
>  
>  It seems to me that the queries are being added to working memory as 
> facts, but the query is not retracted after its result is returned. Is 
> that true? Is there something I need to do so query facts are removed 
> after the results are returned to keep the size of working memory down?
>  
> Has this behavior changed since Drools 4.0.7. I don't recall seeing 
> this issue running against the older version of Drools.
no, after a query the memory should return to before the query was 
executed. If it's not, then there is a memory leak, maybe the retracting 
of the query driver is not happening. If you look at the query method, 
it just inserts a DroolsQuery object and retracts it and gathers up the 
results inbetween. If you have jprofiler you can have a good idea if the 
DroolsQuery object is getting GC'd, or if they are building up.

Mark
>  
> Thanks,
> Dan
>  
> Daniel Quinn
> Fedex - Custom Critical
> Software Specialist I
> 234.310.4090(x2586)
>  
>
> ------------------------------------------------------------------------
> *From:* rules-users-bounces at lists.jboss.org 
> [mailto:rules-users-bounces at lists.jboss.org] *On Behalf Of *David Sinclair
> *Sent:* Friday, April 03, 2009 3:20 PM
> *To:* Rules Users List
> *Subject:* Re: [rules-users] Locating facts via slot values
>
> Here you go WolfGang
>
> rule shoot-3
>     when
>             $h : Hunter( $target : target)
>                   Animal(this == $target)
>     then
>        $h.shoot( $a );
>        retract( $a );
> end
>
> 2009/4/3 Wolfgang Laun <wolfgang.laun at gmail.com 
> <mailto:wolfgang.laun at gmail.com>>
>
>     Given a working memory containing a large number of rather static
>     facts which are from several subclasses (Ape, Bear, Crocodile,...)
>     of some base class (Animal) and a single fact of class Hunter with
>     a field target of type Animal, the shooting of an animal might be
>     written with a rule like this:
>
>     rule shoot-1
>         when
>             ?h : Hunter( ?target : target )
>             ?a : Animal()
>             eval(?target == ?a)
>         then
>            ?h.shoot( ?a );
>            retract( ?a );
>     end
>
>     Avoiding eval (which is said to be inefficient), it could also be
>     written as
>
>     rule shoot-2
>         when
>             ?a: Animal()
>             ?h : Hunter( target  == ?a )
>         then
>            ?h.shoot( ?a );
>            retract( ?a );
>     end
>
>     This, however, places the pattern with many instances up front,
>     which is (AFAIK) not so good in a Rete implementation.
>
>     Which one is to be preferred in Drools?
>
>     Ideally, one might want to write
>
>     rule shoot-3
>         when
>             ?h : Hunter( ?target : target )
>             ?a == ?target : Animal()                   ### not valid DRL
>         then
>            ?h.shoot( ?a );
>            retract( ?a );
>     end
>
>     This avoids eval, has the single instance fact up front, but it
>     isn't available.
>
>     -W
>
>
>
>
>     _______________________________________________
>     rules-users mailing list
>     rules-users at lists.jboss.org <mailto:rules-users at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/rules-users
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20090501/932e3a65/attachment.html