[rules-users] queries in Drools 5.0

[Quinn, Dan]

Mark,
 
  We were using JRockit's Mission Control to monitor memory. The working
memory footprint just kept growing even though we were only querying
working memory and weren't adding new facts. I'm new to the Mission
Control application and couldn't figure out how to configure it to
verify queries were causing the footprint to grow. I just made that
assumption since we were only querying working memory and not adding new
facts.
  I will look into it more today, and use JProfiler to verify queries
are causing the footprint to grow. If I verify that, I will put together
a use case that demonstrates the problem. Thanks for looking into this
for me.
 
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 Mark Proctor
Sent: Thursday, April 30, 2009 9:13 PM
To: Rules Users List
Subject: Re: [rules-users] queries in Drools 5.0


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>
	

		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
		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/20090504/e189f9a6/attachment.html