[rules-dev] SessionPseudoClock and System Time

[Wolfgang Laun]

The SessionPseudoClock is invaluable for testing rule sets using temporal
operators and STREAM-related features based on Time.

While all Engine activity due to the artificial advancing of the clock is
taken care of, the other side of the coin becomes apparent as soon as
actions outside the Engine are based on System Time. Several methods must be
redirected to the Session(Pseudo)Clock, but this can be handled with some
helper classes. But there are several methods where System Time is used
implicitly. One of these is Lock.tryLock( int, TimeUnit ), another one is
Condition.awaitUntil( Date ). I think that these situations can be handled
with tolerable effort using the facilities of org.drools.time and the
PseudoClockScheduler (implementing SessionPseudoClock) methods scheduleJob
and removeJob.

But all of the aforementioned types are "unstable", including
SessionPseudoClock with the essential method advanceTime(long), even though
the Fusion manual claims that "Drools ... offers out of the box ... a clock
that is controlled by the application" (sic!).

What this amounts to is me crabbing again of being lured into the unstable
parts of the API by the "official" announcement of some feature. On Madison
Avenue they call this a "teaser".

Cheers
Wolfgang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20101114/48bb1ac7/attachment.html