[rules-users] Snapshot of drools engine's state

[Wolfgang Laun]

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 at 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-tp4025457p4025471.html
> Sent from the Drools: User forum mailing list archive at Nabble.com.
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>