1. In cases like this, either you define an @expires policy that is longer than your temporal constraints + latency to receive the events, or you run the engine in cloud mode (disabling the lifecycle management).
2. Yes, correct. As you probably realized, given only the constraint in your example, the same B could match multiple A's.
The first one is kind of ... ugly.
I know the stream mode needs a time-ordered stream so that the
processing can be done correctly. In my case it can not really be
predicted at which time an event arrives so that the
system/application clock and the timestamp contained in the events
are not synchronous.
Let's say that delta-t is the relation between the time a object is
send and received. The send time is reflected by the timestamp of
the object which is referenced using @timestamp. In my case there
does no Delta-t exists that expresses sendTime+Delta-t=receiveTime.
Therefore a event A with ts=10h15m03s10ms can arrive at
tr=10h15m04s49ms and a event B with ts=10h15m17s30ms can arrive at
tr=10h15m20s55ms.
If I've got now the rule
$a : A()
$b : B(this after[0,20s] $a)
Will the engine 'count' and wait the 20 seconds for a appropriate
event B? Or how would it work?
The second question is more simple.
If I use
$a : A()
$b : B( this before[0,3m] $a )
How does the engine handle the automatic life cycle managment? Will
every B will be kept for 3 minutes to see if there will be a related
A?
Thank you! :)
Tina
Drools also use the 13 temporal operators as "hints", so if you
have a rule:
$a : A()
$b : B( this after[0,3m] $a )
Drools will know that A's must be held in memory for 3
minutes while B's will expire immediately. Drools will calculate
all possible expiration offsets based on all used temporal
operators.
In case no expiration offset can be calculated for a given
event (i.e., no temporal operator was used, no sliding window,
no @expires policy, resulting in expiration offset to be
infinity), the event is help in memory until explicitly
retracted.
I'm thinking about something. Maybe anyone can tell me.
The Stream Processing Mode of Drools Fusion provides
automatic lifecycle
managment. For my understandings this is based on the
sliding windows
used inside the rule conditions, the @expires metadata and
the @delay
metadata. Am I right so far?
My questions is now: How are Events handled if non of the
things listed
above are used?
Let's say I've got rules just using the temporal reasoning
operators
inside the rule conditions - no sliding windows at all. I'm
also not
using any of the @expires and @delay metadata. Is it correct
than that:
- Drools matches the event coming in and the events
existing in the
KnowledgeBase and eventually activates a rule. And after
fireAllRules()
is called the resulting actions are performed and all Events
are
retracted by the automatic lifecycle managment, because
there are no
hints (like a sliding window) that events will be needed
again. (So that
the knowledge base would be empty again?)