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/jav...
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(a)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":
https://github.com/droolsjbpm/drools/blob/master/drools-compiler/src/test...
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(a)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(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/rules-users