[rules-users] Does Session effeciently filter unused facts, or...

Edson Tirelli ed.tirelli at gmail.com
Tue Nov 24 19:00:20 EST 2009


   Greg, I believe I fixed this bug in trunk a few weeks ago. Although I
confess I did not understood the intent of your rules... :)

   Barry, you can certainly go either way. Rete is very efficient on
filtering fact types, but of course there is some overhead on fact handle
creation. If performance is acceptable for you by just inserting events and
letting the engine discard them automatically when not used, I would not
worry about. If you are having performance problems due to the volumes of
non-interesting events and you want to try pre-filtering, I can give you
some pointers on how to find the fact types used by your rules/queries. In
this case, we might even make a feature of that and have the "pre-filter"
being executed by the engine... ;)

   Edson

2009/11/24 Greg Barton <greg_barton at yahoo.com>

> Well, I was about to say "you could do this using rule inheritance" but
> there is a caveat, and possibly a bug.  It almost works. :)
>
> Try this:
>
> rule "BaseStream1Criteria"
>        enabled false
>        when
>                m : Message( foo == "BAR" ) from entry-point "Stream1"
>        then
>                System.out.println( "BaseStream1Criteria" );
> end
>
> rule "SubRule1" extends "BaseStream1Criteria"
>        when
>                Message( status == Message.HELLO ) from m;
>        then
>                System.out.println( "SubRule1 " );
> end
>
> rule "BaseStream2Criteria"
>        enabled false
>        when
>                m : Message( foo == "BAS" ) from entry-point "Stream2"
>        then
>                System.out.println( "BaseStream2Criteria" );
> end
>
> rule "SubRule2" extends "BaseStream2Criteria"
>        when
>                Message( status == Message.HELLO ) from m;
>        then
>                System.out.println( "SubRule2 " );
> end
>
> Basically, define one rule for each entry point that has the global
> criteria for that entry point.  Then extend that rule.
>
> The caveat is that it seems you can't use the events matched in the
> super-rule in the RHS of the subrule. (Try putting the object "m" matched
> into the action of either of the subrules.  It neither validates in eclipse
> nor compiles at runtime, drools 5.0.1.)  If this isn't fixed in trunk (I
> can't check at the moment) I'll open a jira.
>
> Code attached.  When you run it, this should be the output:
>
> SubRule2
> SubRule1
>
> --- On Mon, 11/23/09, Barry Kaplan <groups1 at memelet.com> wrote:
>
> > From: Barry Kaplan <groups1 at memelet.com>
> > Subject: [rules-users]  Does Session effeciently filter unused facts,
> or...
> > To: rules-users at lists.jboss.org
> > Date: Monday, November 23, 2009, 9:12 PM
> >
> > ... should I put a filter before insert().
> >
> > I will have lots of events coming from hardware devices,
> > only some of which
> > be applicable to a given session instance. I've tried
> > extracting the
> > declared types from the packages, but that doesn't include
> > classes used in
> > patterns which where only imported. So determine the actual
> > set of event
> > classes used by a given set of packages seems not to be so
> > easy.
> >
> > I've drilled down to EntryPointNode.assertObject......
> > --
> > View this message in context:
> http://old.nabble.com/Does-Session-effeciently-filter-unused-facts%2C-or...-tp26489782p26489782.html
> > Sent from the drools - user mailing list archive at
> > Nabble.com.
> >
> > _______________________________________________
> > 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
>
>


-- 
 Edson Tirelli
 JBoss Drools Core Development
 JBoss by Red Hat @ www.jboss.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20091124/8f1a62d4/attachment.html 


More information about the rules-users mailing list