The SessionPseudoClock is invaluable for testing rule sets using temporal operators and STREAM-related features based on Time.<br><br>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. <br>
<br>But all of the aforementioned types are &quot;unstable&quot;, including SessionPseudoClock with the essential method advanceTime(long), even though the Fusion manual claims that &quot;Drools ... offers out of the box ... a clock that is controlled by the application&quot; (sic!). <br>
<br>What this amounts to is me crabbing again of being lured into the unstable parts of the API by the &quot;official&quot; announcement of some feature. On Madison Avenue they call this a &quot;teaser&quot;.<br><br>Cheers<br>
Wolfgang<br><br><br>