[rules-users] Drools STREAM Mode performance with rather simple rule

[Wolfgang Laun]

And, I hope, it doesn't matter in which order the Events A with id x are
matched with Events B with the same id.

The idea of my approach is to make the Events  A, B, C not directly visible
to the rule ABC but through a "filter" fact, one per type (A, B. C) and per
id.

Here is the abstract base class for the filter fact; Event is the base class
for the three EventA/B/C (or use Object).

package event;
import java.util.*;
public abstract class EventList {
    private String id;
    private List<Event> list;
    public EventList( int id ){
        this.id = "" + id;
        list = new ArrayList<Event>();
    }
    public String getId(){
        return id;
    }
    public int size(){
        return list.size();
    }
    public void add( Event event ){
        list.add( event );
    }
    public void delFirst(){
        list.remove( 0 );
    }
}

Here is the insertion:

        long t0 = System.currentTimeMillis();
        int limit = 10;
        EventListA[] aList = new EventListA[limit];
        EventListB[] bList = new EventListB[limit];
        EventListC[] cList = new EventListC[limit];
        int count = 100;
        for( int i = 0; i < limit; i++ ){
            aList[i] = new EventListA( i );
            bList[i] = new EventListB( i );
            cList[i] = new EventListC( i );
            for( int j = 0; j < count; j++ ){
                EventA eventA =  new EventA( i );
                aList[i].add( eventA );
                session.insert( eventA );
                EventB eventB =  new EventB( i );
                bList[i].add( eventB );
                session.insert( eventB );
                EventC eventC =  new EventC( i );
                cList[i].add( eventC );
                session.insert( eventC );
            }
            session.insert( aList[i] );
            session.insert( bList[i] );
            session.insert( cList[i] );
        }
        session.fireAllRules();
        long t1 = System.currentTimeMillis();
        System.out.println( "id limit " + limit + ", execution of " + count
+ " identical triples: " + (double)(t1-t0)/1000.0 );

Here's the rules:

rule ABC
when
  $a : EventListA( $aid: id, size > 0 )
  $b : EventListB(id == $aid, size > 0 )
  $c : EventListC(id == $aid, size > 0 )
then
  $a.delFirst();
  update( $a );
  $b.delFirst();
  update( $b );
  $c.delFirst();
  update( $c );
  // …(actions)
end

rule killEmtpyList
when
    $el: EventList( $id :  id, size == 0 )
then
    System.out.println( "retracted " + $el.getClass().getSimpleName() + $id
);
    retract( $el );
end

There are a couple of things to watch out for, and to refine.
* You may want to keep track of existing EventListX in maps, or use a couple
of rules to create and add new EventX to their EventListX.
* Perhaps another collection type is more efficient than ArrayList; depends
on how many Xs with identical ids you expect.
* make sure to update after EventList.add and .delFirst, also when doing it
in Java code. (My insert sequence inserts the completed EventList.)

An entirely different approach might be possible using temportal operators,
provided the events have distinct timestamps:
   $a: EventA( $id : id, marked == false )
   not EventA( if == $id, this before $a, marked == false )
   // same for B, C
but here you'll have to retract the "winners" or else mark them as matched.

HTH
-W


2010/11/15 Roess. Oliver <o.roess at seeburger.de>

>
>  Hello again!
>
>
>
> Thanks for the heads up, Wolfgang.
>
>
>
> Basically, what I try to create is some sort of batch window, which is not
> really implemented into Drools Fusion if I remember correctly.
>
> It doesn’t HAVE to be A, B, C in that particular order which I specified in
> my last post, but the rule shall only match each A, each B, and each C once.
> So what would you recommend as a best practise to build that rule? Or is my
> rule correct? Actually, I don’t like the fact, that I have to complete the
> rule by retracting my events in the RHS of the rule. I’d rather have a batch
> window specified in the LHS. Thanks in advance.
>
>
>
> Best regards,
>
> Oliver
>
>
>
>  *SEEBURGER AG*   Vorstand/Seeburger Executive Board:  Sitz der
> Gesellschaft/Registered Office:   Bernd Seeburger, Axel Haas, Michael
> Kleeberg  Edisonstr. 1    D-75015 Bretten Vorsitzender des
> Aufsichtsrats/Chairperson of the Seeburger Supervisory Board:  Tel.: 07252
> / 96 - 0 Dr. Franz Scherer  Fax: 07252 / 96 - 2222   Internet:
> http://www.seeburger.de Registergericht/Commercial Register:  e-mail:
> info at seeburger.de HRB 240708 Mannheim
>
>
> Dieses E-Mail ist nur für den Empfänger bestimmt, an den es gerichtet ist
> und kann vertrauliches bzw. unter das Berufsgeheimnis fallendes Material
> enthalten. Jegliche darin enthaltene Ansicht oder Meinungsäußerung ist die
> des Autors und stellt nicht notwendigerweise die Ansicht oder Meinung der
> dar. Sind Sie nicht der Empfänger, so haben Sie diese E-Mail irrtümlich
> erhalten und jegliche Verwendung, Veröffentlichung, Weiterleitung, Abschrift
> oder jeglicher Druck dieser E-Mail ist strengstens untersagt. Weder die noch
> der Absender (Oliver Roess) übernehmen die Haftung für Viren; es obliegt
> Ihrer Verantwortung, die E-Mail und deren Anhänge (0) auf Viren zu prüfen.
>
> The present email addresses only the addressee which it targets and may
> contain confidential material that may be protected by the professional
> secret. The opinions reflected herein are not necessarily the one of the .
> If you are not the addressee, you have accidentally got this email and are
> not enabled to use, publish, forward, copy or print it in any way. Neither
> the , nor the sender (Oliver Roess) are liable for viruses, being your own
> responsibility to check this email and its attachments (0) for this purpose.
>
>
>
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20101115/ea094c96/attachment.html