How to retract events that don't match any rules (without @expires())

[Ladd]

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

[laune]

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 <[hidden email]> 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-any-rules-without-expires-tp4018760.html
> Sent from the Drools: User forum mailing list archive at Nabble.com.
> _______________________________________________
> rules-users mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/rules-users
>

_______________________________________________
rules-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-users

[Ladd]

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

[Davide Sottara]

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 :)

[Ladd]

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

[laune]

On 19/07/2012, Ladd <[hidden email]> 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
_______________________________________________
rules-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-users

[laune]

On 19/07/2012, Wolfgang Laun <[hidden email]> wrote:

>    $b.modify{ incCount() }

Even thought this looks nice, one still has to write it like so:

   modify( $b ){ incCount() }

-W
_______________________________________________
rules-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-users

[Mark Proctor]

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-any-rules-without-expires-tp4018760.html
> Sent from the Drools: User forum mailing list archive at Nabble.com.
> _______________________________________________
> rules-users mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/rules-users

_______________________________________________
rules-users mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-users

[Ladd]

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