12:59 p.m.
Hello,
Recently I've been using Drools (version 5.0.1) to build a small sensor
monitoring application and have run into memory consumption issues that seem
to be related to logically inserted facts. The way it is set up there are
Sensor facts which carry numerically encoded "flags" that can signal certain
properties about that Sensor. My intent was to create rules to detect these
flags and insert marker facts in order to abstract how flagging is handled
and make it easier for other rules to use this information. Here is an
example of the rules I'm using:
declare DeltaFlagged
sensor : Sensor @key
end
rule "Delta Flagged"
agenda-group "delta flag inference"
auto-focus true
when
$sensor: Sensor(eval(isDeltaFlag(flag)))
then
DeltaFlagged flagged = new DeltaFlagged();
flagged.setSensor($sensor);
insertLogical(flagged);
end
Each Sensor is updated at regular intervals from outside of the rule engine,
several hundred times a day. Similar to the examples given here (
http://blog.athico.com/2007/03/writing-rules-for-monitoring-and-time.html).
This works very well for short periods of time. However, after many
days of operation I can observe a clear memory leak trend. When I inspect a
memory dump I see that there are many LogicalDependency objects created and
stored by the truth maintenance system (on the order of several million) for
each "flag" fact that has been logically inserted. Only one fact is being
inserted per Sensor as expected. I am working under the impression that
Drool's truth maintenance should not be recording duplicate dependencies, so
I'm wondering what I have done wrong with the equals() and hashcode()
methods of my objects to cause Drools to treat each activation of this rule
as a new dependency. My Sensor objects use the default hashcode and equals
methods. Thank you in advance.
Bill
2:21 a.m.
Will isDeltaFlag(flag) ever return false after an update to a Sensor object?
(If not I'd say that this is at the root of the problem, but I doubt that
logical is the preferred choice here.)
Which truth do you want to be maintained by the DeltaFlagged facts?
What is the ultimate purpose of DeltaFlagged facts being around galore
in this constantly changing scenario?
-W
2010/5/6 bill simms <sitrious(a)gmail.com>:
Hello,
Recently I've been using Drools (version 5.0.1) to build a small sensor
monitoring application and have run into memory consumption issues that seem
to be related to logically inserted facts. The way it is set up there are
Sensor facts which carry numerically encoded "flags" that can signal certain
properties about that Sensor. My intent was to create rules to detect these
flags and insert marker facts in order to abstract how flagging is handled
and make it easier for other rules to use this information. Here is an
example of the rules I'm using:
> declare DeltaFlagged
> sensor : Sensor @key
> end
>
> rule "Delta Flagged"
> agenda-group "delta flag inference"
> auto-focus true
> when
> $sensor: Sensor(eval(isDeltaFlag(flag)))
> then
> DeltaFlagged flagged = new DeltaFlagged();
> flagged.setSensor($sensor);
> insertLogical(flagged);
> end
Each Sensor is updated at regular intervals from outside of the rule engine,
several hundred times a day. Similar to the examples given here (
http://blog.athico.com/2007/03/writing-rules-for-monitoring-and-time.html
). This works very well for short periods of time. However, after many
days of operation I can observe a clear memory leak trend. When I inspect a
memory dump I see that there are many LogicalDependency objects created and
stored by the truth maintenance system (on the order of several million) for
each "flag" fact that has been logically inserted. Only one fact is being
inserted per Sensor as expected. I am working under the impression that
Drool's truth maintenance should not be recording duplicate dependencies, so
I'm wondering what I have done wrong with the equals() and hashcode()
methods of my objects to cause Drools to treat each activation of this rule
as a new dependency. My Sensor objects use the default hashcode and equals
methods. Thank you in advance.
Bill
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
9:02 a.m.
Thanks for replying.
1. Yes isDeltaFlag(flag) should eventually return false. But when it does
so is dependent on when the Sensor's flag value changes. If the Sensor
remains flagged for long periods of time, the rule will continue to activate
for each update to the Sensor. There are several
other types of flags, which may also exist for long periods of time.
2. The truth to be maintained here is simply that a Sensor has a particular
flag, in this case a Delta flag, set on it. I'm using such rules to reduce
the need to eval() in other rules that react to the presence of a flag in
more meaningful ways. I'm using eval() with a function because the flags
are originally encoded by setting bits at specific positions to 1. I have
not seen a better way of doing this yet.
3. The ultimate purpose for DeltaFlagged, and other similar facts, is to be
used for triggering other rules which take more complicated actions. Again,
I have taken this approach to avoid repeating eval() in many different
rules, and to abstract what a flag is.
rule "Example Flag Rule"
when
$station: Station($stationId : stationId)
$test: DeltaFlaggedTest(stationId == $stationId, $sensorId :
sensorId)
$flag: DeltaFlagged($sensor : sensor)
Sensor(this == $sensor, station == $stationId, id
== $sensorId)
then
// Send messages, make database changes, etc.
end
By using insertLogical() I was hoping to ensure that one and only one
DeltaFlagged fact was inserted for a Sensor, and was automatically
retracted, using only one rule. In addition, I have used logical inserts
for other possibly-long-running facts. Based on my research so far, I will
need to alter my approach to avoid any long-term logically asserted facts
that are frequently updated. My original email was to ask about how fact
equality plays a role in logical inserts. But now I think I have clarified
to myself that equality was not the problem. Using logical inserts under
these long-term scenarios was my problem.
-B
5628
days inactive
5629
days old
2 comments
2 participants
participants (2)
-
bill simms -
Wolfgang Laun