On 30 January 2012 17:18, Philipp Herzig <[email protected]> wrote:
> Thanks Wolfgang for your reply. > > doSomething simply persists something with JPA, no events are > retracted or updated. The behavior does also not change when there is > a simple println in the then clause. > > OK. > I thought events are automatically retracted once no rule applied > anymore. The EventObject class with the map is used only for > abstraction within the architecture (actually a property pattern). No > intention to speed up something. > There's no information in the (only) rule that would permit an automatic retraction. Mostly this is possible when temporal operators are used. Searching for EventObject/create without matching EventObject/delete is causing a lot of work, since each insertion requires an exhaustive linear search for the absence of a delete or the presence of a create. What do you call after the bunch insert? fireAllRules() ? -W As I said, the activation firing works fine when no timer is present > and, of course, deletes are already inserted before the creates, > otherwise the rule won't fire. > > Do you know how the Scheduler works? According to the observed > behavior I would guess that there is a background job invoked every > 100ms checking if there are timer delayed activations which has to be > fired. > If this is the case, I wonder why only some activations are fired and > not all. Due to the upper time bound? > > Thanks again, > > Philipp > > > 2012/1/30 Wolfgang Laun <[email protected]>: > > Does the doSomething() update or retract any EventObject facts and notify > > the Drools engine accordingly? > > > > (So far: Neither using the same class for the "create" and the "delete" > > events nor > > using a map (i.e., "data") for all properties is helping w.r.t. speed.) > > > > -W > > > > > > On 30 January 2012 15:07, Philipp Herzig <[email protected]> wrote: > >> > >> Sure, here it is. Sorry for any inconvienience! > >> > >> rule "new_intent" > >> timer (20s) > >> when > >> $evt : EventObject(data['type']=='create') from entry-point > >> eventstream > >> not ( EventObject(data['type']=='delete', > >> data['mrid']==$evt.data['mrid'], data['userid']==$evt.data['userid']) > >> from entry-point eventstream) > >> then > >> SomeAPI.getInstance().doSomething(); > >> end > >> > >> > >> Thank you, > >> > >> Philipp > >> > >> > >> > >> > >> 2012/1/30 Michael Anstis <[email protected]> > >> > > >> > It's going to help (probably) if you include the definition of your > rule > >> > (or rules). > >> > > >> > 2012/1/30 Philipp Herzig <[email protected]> > >> >> > >> >> Dear Community, > >> >> > >> >> Drools is pretty fast regarding all my use cases. However, today I > have > >> >> found a problem where I cannot find any solution. Hopefully someone > of you > >> >> can help. > >> >> > >> >> 1. I have a rule with a @timer(10s) attribute (should be 24h later on > >> >> but doesn't matter). This rule is activated when a "create" event > occurs and > >> >> invalidated once a "delete" event occurs within the timeframe of > @timer. > >> >> > >> >> 2. I have approx. 9000 "create" events which are bulk loaded into the > >> >> working memory and creating activations for the rule above. > >> >> > >> >> 3. I have approx. 2000 "delete" events which are bulk loaded into my > >> >> entry-point cancelling the respective activations from step (2) > >> >> > >> >> 4. After the timer expired, the first activation is fired correctly. > >> >> However, all other activations are fired with some noticeable delay > >> >> (actually it needs 20-30minutes until all activations are fired). > >> >> > >> >> > >> >> Do you have an idea what the problem with the timer might be? > >> >> Unfortunately, I have neither an idea how the scheduler in the > background > >> >> works nor which class I should start looking at. > >> >> > >> >> BTW: For testing purpose I switched step (2) & (3), that is, "delete" > >> >> events are inserted before the "create" events and removed the timer > >> >> attribute which is obviously the same logic. It performs lightning > fast in > >> >> this case... (all remaining activations are fired within 5 > >> >> seconds). However, insertinging my "delete" events before the > "create" > >> >> events is ok for testing but not feasible in practice. > >> >> > >> >> It would be great if some of you has an idea or point to start within > >> >> the code. > >> >> > >> >> Thanks in advance, > >> >> > >> >> Philipp > >> >> > >> >> _______________________________________________ > >> >> rules-users mailing list > >> >> [email protected] > >> >> https://lists.jboss.org/mailman/listinfo/rules-users > >> >> > >> > > >> > > >> > _______________________________________________ > >> > rules-users mailing list > >> > [email protected] > >> > https://lists.jboss.org/mailman/listinfo/rules-users > >> > > >> > >> > >> > >> -- > >> -------------------------------------------- > >> Philipp Herzig, M.Sc. > >> > >> Mail: [email protected] > >> Cell: 0178 - 6156244 > >> > >> _______________________________________________ > >> rules-users mailing list > >> [email protected] > >> https://lists.jboss.org/mailman/listinfo/rules-users > > > > > > > > _______________________________________________ > > rules-users mailing list > > [email protected] > > https://lists.jboss.org/mailman/listinfo/rules-users > > > > > > -- > -------------------------------------------- > Philipp Herzig, M.Sc. > > Mail: [email protected] > Cell: 0178 - 6156244 > > _______________________________________________ > rules-users mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/rules-users >
_______________________________________________ rules-users mailing list [email protected] https://lists.jboss.org/mailman/listinfo/rules-users
