9:01 p.m.
Is there a recommended way to remove events from working memory that don't
match and can't activate any rules?
For example, let's say I have two rules which should both fire when a person
with name "Bob" is encountered. If a person with name "Jim" comes in
he
stays in working memory forever even though he doesn't match any current
rules.
I know @expires() for Person events would work. But I don't know what a
"safe" time would be since I don't know ahead of time what temporal rules
might be written for them.
From the 5.4.0 Drools Fusion docs (Chapter 2) I found these
statements:
/"In other words, one an event is inserted into the working memory, it is
possible for the engine to find out when an event can no longer match other
facts and automatically retract it, releasing its associated resources."/
/"Events may be automatically expired after some time in the working memory.
Typically this happens when, based on the existing rules in the knowledge
base, the event can no longer match and activate any rules. Although, it is
possible to explicitly define when an event should expire."/
Based on this statement I would expect my "Jim" to be automatically expired
after "some time". Maybe it will be and I'm just not waiting long enough.
But then I found this quote from Edson:
/"Any object type for which there are no explicit
expiration policy, nor temporal constraints from which to derive the
expiration offset will have an infinite expiration offset, i.e., will never
be automatically retracted."/
So my question is, how can I retract events which don't match any rules?
Thanks in advance for any tips or suggestsions!!
- Ladd
--
View this message in context:
http://drools.46999.n3.nabble.com/How-to-retract-events-that-don-t-match-...
Sent from the Drools: User forum mailing list archive at Nabble.com.
9:12 p.m.
If a fact is to be matched right after insertion the solution is
simple: add a rule with low salience matching and retracting the fact.
If you expect/hope that it matches later and you have a time limit,
@expires is the answer.
The interesting case is when you don't have the time limit and still
hope for a match. If you have a convincing use case for that, I might
be enticed to develop a solution for that ;-)
-W
On 18/07/2012, Ladd <ladd(a)codemettle.com> wrote:
Is there a recommended way to remove events from working memory that
don't
match and can't activate any rules?
For example, let's say I have two rules which should both fire when a
person
with name "Bob" is encountered. If a person with name "Jim" comes in
he
stays in working memory forever even though he doesn't match any current
rules.
I know @expires() for Person events would work. But I don't know what a
"safe" time would be since I don't know ahead of time what temporal rules
might be written for them.
>From the 5.4.0 Drools Fusion docs (Chapter 2) I found these statements:
/"In other words, one an event is inserted into the working memory, it is
possible for the engine to find out when an event can no longer match other
facts and automatically retract it, releasing its associated resources."/
/"Events may be automatically expired after some time in the working
memory.
Typically this happens when, based on the existing rules in the knowledge
base, the event can no longer match and activate any rules. Although, it is
possible to explicitly define when an event should expire."/
Based on this statement I would expect my "Jim" to be automatically expired
after "some time". Maybe it will be and I'm just not waiting long enough.
But then I found this quote from Edson:
/"Any object type for which there are no explicit
expiration policy, nor temporal constraints from which to derive the
expiration offset will have an infinite expiration offset, i.e., will never
be automatically retracted."/
So my question is, how can I retract events which don't match any rules?
Thanks in advance for any tips or suggestsions!!
- Ladd
--
View this message in context:
http://drools.46999.n3.nabble.com/How-to-retract-events-that-don-t-match-...
Sent from the Drools: User forum mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
10:08 p.m.
Thanks for the super fast reply W!
The problem with retracting with a low salience is that my rule set is
fairly dynamic. Rules come and go. And we have lots of event types and
lots of fields within them to match on.
Some rules may match an event immediately. Ex:
when
$p : Person( name == "Bob" )
Some may be "and"s, "or"s, etc. Ex:
when
$first : MyEvent( key == "first" )
$person : Person( name == "Bob" )
Some rules may be temporal with time constraints which I don't know in
advance. Ex:
when
$first : MyEvent( key == "first" )
$second : MyEvent( key == "second", this after [ 0s 10s ] $first )
Some may be temporal with no time constraints. Ex:
when
$first : MyEvent( key == "first" )
$second : MyEvent( key == "second", this after $first )
I don't see how I can use @expires() since I don't know at compile time what
the maximum temporal time limit will be. Best I could do is create one (say
1 week) and rule developers would have to live within that limit.
And I can't use retract() since any event may be part of a "compound" rule
that's waiting for the other condition(s) to be met.
As for the use case with no time limit, would your workaround for the
window.length(1) bug be an example?
when
f1 : MyEvent( key == "faultType1", value == "ALARM" )
not MyEvent( key == "faultType1", this after f1 )
f2 : MyEvent( key == "faultType2", value == "ALARM" )
not MyEvent( key == "faultType2", this after f2 )
then
System.out.println( "************ BOTH FAULTS ARE ACTIVE!" )
We need to detect when multiple events are in a given state at the same
time. Order doesn't matter. Time between events doesn't matter.
Again, thanks for taking the time to help!
- Ladd
--
View this message in context:
http://drools.46999.n3.nabble.com/How-to-retract-events-that-don-t-match-...
Sent from the Drools: User forum mailing list archive at Nabble.com.
11:04 p.m.
If your rules are dynamic, would you still want to retract a fact not
matching any of your current rules,
knowing that a new rule might appear later, which would be activated by that
fact?
This said, the problem here is "garbage-collecting" facts which have been
insert, but are in a "zombie"
status, since there is no pattern matching them - not even partially. This
could be a useful feature (Mario?),
you could open a feature request JIRA and let the developers discuss it.
For now I would suggest this: whenever you insert an object, you will get
back a FactHandle.
Cast it to org.drools.common.InternalFactHandle and look at
getFirstLeftTuple() and getFirstRightTuple().
I haven't checked it completely, but I would say that if the fact does not
participate in any tuple, it
might be worthy retracting.
Best
Davide
ps your case "second after first" is a well known problem... and not only
for drools! If your "first"
matches your conditions, it will have to stay there waiting for a
"second"... You'll have to
"close the horizon" explicitly to remove those "firsts" which have
been
there for "too long", whatever
that means for you :)
--
View this message in context:
http://drools.46999.n3.nabble.com/How-to-retract-events-that-don-t-match-...
Sent from the Drools: User forum mailing list archive at Nabble.com.
12:19 a.m.
Davide Sottara wrote
If your rules are dynamic, would you still want to retract a fact not
matching any of your current rules,
knowing that a new rule might appear later, which would be activated by
that fact?
That's a good question. Smaller memory footprint by retracting. But we
lose the immediate activation of future rules. Maybe I'll make it an option
and let somebody else decide. ;)
Davide Sottara wrote
For now I would suggest this: whenever you insert an object, you will get
back a FactHandle.
Cast it to org.drools.common.InternalFactHandle and look at
getFirstLeftTuple() and getFirstRightTuple().
I haven't checked it completely, but I would say that if the fact does
not participate in any tuple, it
might be worthy retracting.
That's great info!! Worked like a charm.
Once again, thanks guys! You've been extremely helpful.
- Ladd
--
View this message in context:
http://drools.46999.n3.nabble.com/How-to-retract-events-that-don-t-match-...
Sent from the Drools: User forum mailing list archive at Nabble.com.
8:39 a.m.
On 19/07/2012, Ladd <ladd(a)codemettle.com> wrote:
That's a good question. Smaller memory footprint by retracting. But we
lose the immediate activation of future rules. Maybe I'll make it an
option
and let somebody else decide. ;)
Here's a plausible idea, which might be useful - I still don't
understand the scenario well enough to be confident ;-)
You can retract rules and still keep them in the game. Let's say X()
is the type for the ones you'd consider to retract, and Y() are the
ones that would expect to match with X(), no matter how old.
rule "make X dormant
when
$b: Bed()
$x: X( ... decisions ... ) // or simply not Y() // or both combined
then
retract( $x );
$server.putToBed( $x );
$b.modify{ incCount() }
end
rule "awaken all X"
when
$b: Bed( count > 0 )
exists Y()
then
$server.getFromBed( $b );
end
If you have many classes like X() or Y(), simply add a marker
interface to these classes.
There's an infinite number of strategies for "putting to bed". LFU
comes to my mind, in addition to age.
Of course, eventually the Bed will fill up; this just postpones the
issue to decide when really to dispatch them to the bit bucket.
-W
7:22 a.m.
You could also look at the declarative agenda stuff, which is
experimental at the moment. With this you can track if there are any
activations that need to fire for a rule. When there are no activations
still to fire, you can iterate and retract facts.
You could probably even correlate specific objects with activation
bindings, using 'not', to determine if it can be retracted.
Mark
On 18/07/2012 20:01, Ladd wrote:
Is there a recommended way to remove events from working memory that
don't
match and can't activate any rules?
For example, let's say I have two rules which should both fire when a person
with name "Bob" is encountered. If a person with name "Jim" comes in
he
stays in working memory forever even though he doesn't match any current
rules.
I know @expires() for Person events would work. But I don't know what a
"safe" time would be since I don't know ahead of time what temporal rules
might be written for them.
>From the 5.4.0 Drools Fusion docs (Chapter 2) I found these statements:
/"In other words, one an event is inserted into the working memory, it is
possible for the engine to find out when an event can no longer match other
facts and automatically retract it, releasing its associated resources."/
/"Events may be automatically expired after some time in the working memory.
Typically this happens when, based on the existing rules in the knowledge
base, the event can no longer match and activate any rules. Although, it is
possible to explicitly define when an event should expire."/
Based on this statement I would expect my "Jim" to be automatically expired
after "some time". Maybe it will be and I'm just not waiting long enough.
But then I found this quote from Edson:
/"Any object type for which there are no explicit
expiration policy, nor temporal constraints from which to derive the
expiration offset will have an infinite expiration offset, i.e., will never
be automatically retracted."/
So my question is, how can I retract events which don't match any rules?
Thanks in advance for any tips or suggestsions!!
- Ladd
--
View this message in context:
http://drools.46999.n3.nabble.com/How-to-retract-events-that-don-t-match-...
Sent from the Drools: User forum mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
3:04 p.m.
Mark Proctor wrote
You could probably even correlate specific objects with activation
bindings, using 'not', to determine if it can be retracted.
I appreciate the tip Mark. I'd like to investigate this. However, you're
talking to a complete Drools novice. Could you point me to a doc or example
that deals with activation bindings?
Thank you!!
- Ladd
--
View this message in context:
http://drools.46999.n3.nabble.com/How-to-retract-events-that-don-t-match-...
Sent from the Drools: User forum mailing list archive at Nabble.com.
4320
days inactive
4322
days old
8 comments
4 participants
participants (4)
-
Davide Sottara -
Ladd -
Mark Proctor -
Wolfgang Laun