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)
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)
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@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users