[rules-users] Future events

[lexsoto]

laune wrote
> 
> You shouldn't base a streamed CEP application on time stamps dealt out
> by various systems with clocks that aren't properly synchronized using
> NTP or whatever. If your data doesn't conform to the very reasonable
> premises of some system, your application will have to handle that.
> 

Correct, I want my application to handle this within the rule engine. This
is why I don't want the rule to be fired if the timestamp is outside the
time window. 



> (You can't tell the engineer to start the train just because your
> clock is fast, right?)
> 

Exactly, and I should not send an alert message for an event that has long
occurred, so I was hoping the rule engine to take care of this for me.  I
have a powerful temporal operator, so why not use it?



> window:time is based on the notion of CEP in real time, and the clock
> of the machine running the engine reads, by definition, true Time....
> 

There are two times here, the sliding time window, and the time of the
event.  The time responsible for sliding the time window is the system
clock.  However, the time of the event is dictated by the event's time
stamp. The engine allows me to declare the event time stamp to be a data
member of the event class:  



By providing this ability, the engine is implicitly promising me to use the
time stamp from the event, as opposed to the time when the event is inserted
in the working memory. 

I have now tested both future and past events and they both cause the rule
to be fired regardless of the event's time stamp. The engine is clearly
ignoring the time stamp as declared and using the insertion time stamp.   If
this is not a bug,  then it is for sure very confusing, and perhaps needs to
be clearly explained that the timestamp from the event is not taken into
consideration by the sliding time window operator.

Thanks,
Alex


--
View this message in context: http://drools.46999.n3.nabble.com/Future-events-tp3826236p3828674.html
Sent from the Drools: User forum mailing list archive at Nabble.com.