Re: [rules-users] Future events
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. ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Future events
Well, yes that is how the engine works. But should it work this way? Why fire the rule if not in the appropriate time window? This still looks wrong to me, as the intention of the rule is not observed. On the per hand, the engine does queue events in other scenarios, so it seems arbritrary. Too bad because this would be a ver nice way to model scheduled events using the temporal operators. Thanks Edson -- View this message in context: http://drools.46999.n3.nabble.com/Future-events-tp3826236p3827065.html Sent from the Drools: User forum mailing list archive at Nabble.com. ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Future events
Thanks Edson for your reply, however I am still not clear about why the rule is firing if the time stamp of the event falls outside the time window. This can happen, for example, if the event originates in a machine with clock slightly ahead. I think the problem also occurs if the time is in the past; I would not want to take action on a future or old event. I understand that events are immutable, and I am not changing the event in any way. However, I expect the "sliding time window" to be changing along with the system clock until it reaches the timestamp of the event. My question still unanswered, why is the rule firing outside its time window? Is there a way to make this work? Any advice about how to address this use case? Thanks -- View this message in context: http://drools.46999.n3.nabble.com/Future-events-tp3826236p3826759.html Sent from the Drools: User forum mailing list archive at Nabble.com. ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
[rules-users] Future events
Hello: I have this rule: An event is inserted that has a timestamp in the future, the rule is fired. This looks like a bug, because the sliding time window has not yet met the timestamp of the event. I expect the rule to fire not immediately but only when the time reaches the event time. Is my assumption/understanding correct? -- View this message in context: http://drools.46999.n3.nabble.com/Future-events-tp3826236p3826236.html Sent from the Drools: User forum mailing list archive at Nabble.com. ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Starting engine using fireUntilHalt and inserting no facts results in 50% CPU usage
My bad, the EAR packaging was wrong causing version 5.1.1 to be the one being deployed (due to other modules included in the EAR). 5.2.0.M1 does indeed fix the high CPU usage. -- View this message in context: http://drools-java-rules-engine.46999.n3.nabble.com/Starting-engine-using-fireUntilHalt-and-inserting-no-facts-results-in-50-CPU-usage-tp1760370p2698129.html Sent from the Drools - User mailing list archive at Nabble.com. ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Starting engine using fireUntilHalt and inserting no facts results in 50% CPU usage
Hello: I see this is marked as fixed in https://issues.jboss.org/browse/JBRULES-2756 https://issues.jboss.org/browse/JBRULES-2756 , but I am still experiencing high CPU usage with version 5.2.0.M1. Anyone still seeing this? This is my first attempt at using Fusion, so I could be doing something wrong. I am not sure about the approach of calling fireAllRules on a timer v.s. the continuous fireUntilHalt. I think I need to keep the session in fire mode all the time to properly catch all events and allow for time sensitive rules to fire, but I don't have the luxury of keeping one of the CPUs at near 100% all the time. Since I am new to CEP, I am not sure what happens to time-window rules in the case of periodically calling fireAllRules. What happens to events inserted into entry-points when the session is not in firing mode? TIA, Alex -- View this message in context: http://drools-java-rules-engine.46999.n3.nabble.com/Starting-engine-using-fireUntilHalt-and-inserting-no-facts-results-in-50-CPU-usage-tp1760370p2697950.html Sent from the Drools - User mailing list archive at Nabble.com. ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
