Re: [rules-users] Snapshot of drools engine's state
The timestamp that is the basis for all calculations done by the engine can be
- a regular field of the class, named in a @timestamp(fieldname) annotation
- a handle field maintained by the engine, set to the session clock
time during insertion (and not readily available to the app)
If you need to keep the one and only timestamp you'll have to use a
regular field and set it to whatever. If you need to "replay" a part
of an aborted session, you'll need to have a pseudo-clock. During the
initial replay phase, the pseudo-clock is driven by the timestamps in
the saved events. Then, you may have to insert some delayed events
that accumulate during the time between a crash and the end of the
replay phase, with the clock still driven by the timestamps in the
events. (Note that this implies that the timestamps ought to reflect
the time of the event's arrival in the system.)
I have found that sliding windows are a bit tricky when the session is
run with a pseudo-clock. Time is frozen between bumps of the clock and
so a window ends when the engine is called again after advancing the
clock. This means that a rule based on a window will not fire at the
"true" end of the window but at the time to which the clock was
advanced. This will still be correct from a logical point of view but
the consequence will execute with a delay. Therefore it may not be
possible to use windows but you should be able to work around that.
-W
On 12/08/2013, IK81 <ml(a)kofler.me> wrote:
I know that this timer inserts real-time. I plan to persists also
the
timestamps when I call these external timer-based fireAllRules invocations.
The problem is that I have to support rules that reason over the
non-occurence of events and not every time I insert a new event. I don't
know how I could realize this otherwise. I'd love to have a kind of
callback
where the engine tells me - wake me up in X seconds so that I can
re-evaluate my rules because then my not-after-N-timeunits rules can fire.
The reason for this approach is that I'll have to ensure that I process
every event but be tolerant against re-starts of my application server. If
I
have a rule - let's say fire if I have event A but no event B after 3
minute
and I insert event A. Let's assume that the application server is rebooted
in the meantime and I start with a clean session, then this rule would
never
fire. Unfortunately, I cannot afford to persist the complete state after
every rule insertion due to performance reasons. However, the events have
to
be persisted anyway. Therefore, I came to this proposal to persist the
state
only after N seconds or insertions as a kind of snapshot. In case of
recovery after a reboot (or transfer of the engine to another cluster node)
I use the snapshot, reinsert the events to get to the same state. However,
this was just my idea how to solve this problem. If you could provide me a
pointer to a better solution I'd also be very thankful.
Thanks for the hint about the timestamp. But isn't the clock of the session
also relevant when inserting new events (which have their own timestamp
provided in the event's POJO?). Therefore, I though that it is necessary to
store both the event's timestamp (which is assigned by an external event
source) and the timestamp when I put it into the engine.
Ingo
--
View this message in context:
http://drools.46999.n3.nabble.com/Snapshot-of-drools-engine-s-state-tp402...
Sent from the Drools: User forum mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users