If you were to wait for the required time and simply call fireAllRules again, the timer base rule (as a result of the not) will be executed.

In 6.1 we now have a special TimerNode:
https://github.com/droolsjbpm/drools/blob/master/drools-core/src/main/java/org/drools/core/phreak/PhreakTimerNode.java

Before the code was a bit of mess, with timers and activations and agendas all melted in together. The lack of separation and async behaviour was making it very hard to write code that was truly thread safe, and we kept finding issues.  The TimerNode now encapsulates all behaviour in a single node, and we ensure no async threads interfere in the main engine network evaluation.

It's role is now more generic - it simply blocks tuple propagations until the timer allows them to be propagated. As mentioned the node is passive, we do not allow the timer thread to interfere with the network evaluation. When it triggers it adds the rule that needs to be evaluated to a queue, which is picked up by the network evaluation thread.  The code sample you are seeing below is allowing a callback mechanism from the timer, so that in passive mode the user can explicitly request an evaluation of that rule. This allows them control of whether an engine in passive mode is async reactive or not, for given rules.

This is actually an important design decision, it will allow us to get greater performance in our new algorithm once we mutli-core it in future releases, without excessive cumbersome locking. It also ensures we have something designed for thread safety, and thread issues can be easily tracked down and resolved.

Also it will allow more functionality in the future, we can expose this as a generic timer CE that can be used in any point of the LHS language, and more than one can be used. Where as at the moment, to emulate 5.x drl, it is hard coded as the final network node.


Mark


On 11 Sep 2013, at 21:27, Mark Proctor <mproctor@codehaus.org> wrote:

Unless you are using fireUntilHalt there is now no longer any async reactivity.  As discussed before, we have a stronger separation now between passive and reactive mode.

If you want to see what's happening, there is now a new trace debug information. You'll need a logback file similar to this, change the "info" to "trace":

We have added an experimental feature that allows the user to provide explicit (rather than implicit) async reaction while in passive execution mode.  Notice how it requires the user to provide a thread for this.

It has one too many unwrap pings to access, so we'll get that changed. But users will still need to cast to an internal interface, to show it's experimental. @mario: please make this a simple cast, instead of unwrapping. The other option is we could add it to the main interface, with javadoc caveats that it's api/signature will change  - but i worry how many people will use the method, without reading the javadocs, and complain once we change it.

We will be looking to have more explicit and declarative control over async behaviour for 6.1

final BlockingQueue<TimedRuleExecution> queue = new LinkedBlockingQueue<TimedRuleExecution>();
((StatefulKnowledgeSessionImpl)ksession).session.setTimedExecutionsQueue(queue);

final AtomicBoolean run = new AtomicBoolean(true);

Thread t = new Thread(new Runnable() {
    public void run() {
        try {
            while (run.get()) {
                queue.take().evauateAndFireRule();
            }
        } catch (InterruptedException e) {
            throw new RuntimeException(e);
        }
    }
});
t.setDaemon(true);
t.start();



On 11 Sep 2013, at 14:16, "Weiss, Wolfgang" <Wolfgang.Weiss@joanneum.at> wrote:

Hi all!
 
I tried out Drools 6.0.0.CR3 and I have some difficulties in detecting patterns with rules containing temporal parameters. I’m using following rule:
 
rule "detect turn shifts"
        agenda-group "evaluation"
        salience 100
       
    when
        $aae : AudioActivityEvent(value >= 50) from entry-point "LowLevelES"
        not(AudioActivityEvent(value < 50, userID == $aae.userID, this after[0, 300ms] $aae) from entry-point "LowLevelES")
    then
        logger.info("turn shift START, user ID: " + $aae.getUserID() + ", " + $aae.toString());
// do something else ...
end
 
When inserting events following happens:
12:43:05,914 [main           ] DEBUG ReteooRuleBase                 - Starting Engine in PHREAK mode
12:43:06,225 [main           ] INFO  SemanticLifter                 - incoming event: AudioActivityEvent [userID=1, value=100.0]
12:43:06,295 [main           ] INFO  SemanticLifter                 - incoming event: AudioActivityEvent [userID=1, value=0.0]
12:43:06,344 [main           ] INFO  SemanticLifter                 - incoming event: AudioActivityEvent [userID=1, value=100.0]
12:43:11,096 [main           ] INFO  SemanticLifter                 - incoming event: AudioActivityEvent [userID=1, value=0.0]
12:43:11,100 [main           ] INFO  SemanticLifter                 - turn shift START, user ID: 1, AudioActivityEvent [userID=1, value=100.0]
...
 
The “turn shift start” should be detected 300ms after the third incoming event (12:43:06,344) which is not the case here. This rule worked for me when using Drools 5.5.0 and 6.0.0.Beta2 but not with 6.0.0.CR3 - I did not try any other version.
This is my code to insert events:
streamEntryPoint = ksession.getEntryPoint("LowLevelES");
...
 
streamEntryPoint.insert(lowLevelEvent);
ksession.getAgenda().getAgendaGroup("evaluation").setFocus();
ksession.fireAllRules();
 
“AudioActivityEvent” is declared as an event with the @role attribute. I also tried to use the following option: “RuleEngineOption.RETEOO”, but with no difference.
 
 
Best regards,
Wolfgang
 
 
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users