[rules-users] A basic doubt about Drools Fusion

[Esteban Aliverti]

I think you have 2 main options here:

   - Invoke fireUnitlHalt() in an independent thread.
   - Invoke fireAllRules() after each insert() you have.

Best Regards,



XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Esteban Aliverti
- Blog @ http://ilesteban.wordpress.com



On Fri, Dec 7, 2012 at 3:57 PM, Adrián Paredes <
adrianp at epidataconsulting.com> wrote:

> Thank you, Esteban.
>
> You are right! If I insert two events A:
>
> rulesTest.addEventA("123");
> rulesTest.addEventA("456");
>
> The second call of fireAllRules() activates the rule for the first object:
>
> Event inserted com.epidataconsulting.drools.model.EventA
> Event A 123 at Fri Dec 07 11:54:21 ART 2012
> Event inserted com.epidataconsulting.drools.model.EventA
>
> But not for the second.
>
> How I can do to correct this behavior?
>
> Thanks!
>
> Adrian
>
>
> 2012/12/7 Esteban Aliverti <esteban.aliverti at gmail.com>
>
>> It could be the case, and I'm guessing here, that the AgendaEventListener
>> is called just before the activation is placed into the agenda. So, the
>> call to fireAllRules() finds an empty agenda. What you could do to check if
>> this is what is happening, is to insert 2 EvenA objects. The second call of
>> fireAllRules() should fire the activation of the first object (and you will
>> miss the activation of the second).
>>
>> Best Regards,
>>
>>
>>
>>
>> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
>>
>> Esteban Aliverti
>> - Blog @ http://ilesteban.wordpress.com
>>
>>
>>
>> On Fri, Dec 7, 2012 at 1:55 PM, Adrián Paredes <
>> adrianp at epidataconsulting.com> wrote:
>>
>>> Hi all:
>>>
>>> I have a very basic doubt about Drools Fusion.
>>>
>>> I have two simple Java classes:
>>>
>>> EventA  {
>>>     String id;
>>>     Date timestamp;
>>>     Long duration;
>>> }
>>>
>>> EventB {
>>>     String id;
>>>     Date timestamp;
>>>     Long duration;
>>> }
>>>
>>> I have a DRL file, where I declare this two classes as Events:
>>>
>>> declare EventA
>>>     @role(event)
>>>     @timestamp(timestamp)
>>>     @duration(duration)
>>> end
>>>
>>> declare EventB
>>>     @role(event)
>>>     @timestamp(timestamp)
>>>     @duration(duration)
>>> end
>>>
>>> I have a simple rule:
>>>
>>> rule "Basic Rule"
>>> dialect 'mvel'
>>> when
>>>     $eventA: EventA($aId: id) from entry-point "time stream"
>>> then
>>>     System.out.println("Event A " + $aId + " at " + $eventA.timestamp);
>>> end
>>>
>>> Finally, I have a test that starts a StatefulKnowledgeSession in STREAM
>>> mode, register an eventLister in the session in order to fire the rules
>>> when an event arrives:
>>>
>>> ksession.addEventListener(new DefaultAgendaEventListener() {
>>>     @Override
>>>     public void activationCreated(ActivationCreatedEvent event) {
>>>         ((StatefulKnowledgeSession)
>>> event.getKnowledgeRuntime()).fireAllRules();
>>>     }
>>> });
>>>
>>> And then the test insert in the "time stream" entry-point an instance of
>>> EventA with duration of 10 miliseconds, as follows:
>>>
>>> EventA eventA = new EventA();
>>> eventA.setId("123");
>>> eventA.setTimestamp(new Date());
>>> eventA.setDuration(10L);
>>> ksession.getWorkingMemoryEntryPoint("time stream").insert(event);
>>>
>>> At the end of the test, I have an sleep of 2 seconds just in case.
>>>
>>> I don't understand why the "Basic Rule" never fires.
>>>
>>> But if I add another condition to the same rule, something like this:
>>>
>>> rule "Basic Rule"
>>> dialect 'mvel'
>>> when
>>>     $eventA: EventA($aId: id) from entry-point "time stream"
>>>     not EventB($aId == id, this after [0s,5s] $eventA) from entry-point
>>> "time stream"
>>> then
>>>     System.out.println("Event A " + $aId + " at " + $eventA.timestamp);
>>> end
>>>
>>> The rules fires and I see this message in console:
>>>
>>> Event A 123 at Fri Dec 07 09:48:59 ART 2012
>>>
>>> I don't understand why the first rule, that is more open, don't fire,
>>> and the second rule, that is more restrictive, fires without problems.
>>>
>>> Thank you very much!
>>>
>>> Greetings,
>>> Adrian.
>>>
>>> --
>>> *Epidata Consulting | Deploying Ideas
>>> Ing. Adrián M. Paredes | Arquitecto Desarrollador
>>> adrianp at epidataconsulting.com | Cel: (54911) 3297 1713
>>>
>>> ----------------------------------------------------------------------------------------------------------------------------
>>> Argentina: Maipú 521 Piso 1 Of. A | Buenos Aires | Of: (5411) 5031 0060
>>> Chile: Apoquindo 3600 Piso 7 y 9 | Las Condes - Santiago | Of: (+56) 2
>>> 495 8450
>>>
>>> ---------------------------------------------------------------------------------------------------------------------------
>>>  www.epidataconsulting.com
>>>  Linkedin <http://bit.ly/epidatalinkedin> | Facebook<http://www.facebook.com/epidata.consulting>
>>>  | Twitter <http://twitter.com/epidata>
>>> *
>>>
>>> _______________________________________________
>>> 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
>>
>>
>
>
> --
> *Epidata Consulting | Deploying Ideas
> Ing. Adrián M. Paredes | Arquitecto Desarrollador
> adrianp at epidataconsulting.com | Cel: (54911) 3297 1713
>
> ----------------------------------------------------------------------------------------------------------------------------
> Argentina: Maipú 521 Piso 1 Of. A | Buenos Aires | Of: (5411) 5031 0060
> Chile: Apoquindo 3600 Piso 7 y 9 | Las Condes - Santiago | Of: (+56) 2
> 495 8450
>
> ---------------------------------------------------------------------------------------------------------------------------
>  www.epidataconsulting.com
>  Linkedin <http://bit.ly/epidatalinkedin> | Facebook<http://www.facebook.com/epidata.consulting>
>  | Twitter <http://twitter.com/epidata>
> *
>
> _______________________________________________
> 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/20121207/84408a8c/attachment.html