[rules-users] Problem with simple Fusion test case

[Wolfgang Laun]

The outlined scenario means that you need to insert facts with a
timestamp that's in the future. In STREAM mode, Drools expects events
to be inserted sequentially ordered by timestamp, at least for each
entry point. Also, a window:time will "contain" future events.

I suggest that you use CLOUD mode, which still lets you use events and
temporal operators and timers. You can effect the expiry of past
programs easily enough by inserting Tick events (1/60 Hz).

A window:time doesn't match overlapping events, it triggers on timestamps.

The pseudo-clock is completely at your mercy, starting at the Big Bang
;-) To set it to now, do:
   clock.advance( (new Date()).getTime(), TimeUnit.MILLISECONDS );

You can let Drools add the timestamp on insertion, or tell Drools that
it is a fact attribute.

Automatic retraction depends on the use of timestamps in rules or on
the explicit setting; it's only available in STREAM mode. (See Example
2.19 in Fusion 2.8.2, Inferred Expiration Offset.)

-W



On 17/04/2012, RobinMacharg <robin.macharg at gmail.com> wrote:
> Thanks for your reply, Wolfgang.
>
> I forgot to say yesterday I'm using Drools 5.3.0.Final, if that makes any
> difference.
>
>
> laune wrote
>>
>> There is a fundamental misunderstanding on your side.
>>
>
> I though as much!  What I'd like to do is clear my misunderstanding up.
>
>
> laune wrote
>>
>> An event's timestamp and duration are used for reasoning, relating
>> events by means of temporal operators, e.g., A before B, A meets B,
>> and so on.
>>
>
> This implies that @timestamp, @duration etc. are only used to relate events
> together, and that they do not relate the event to the clock.  I had
> understood that Fusion would automatically retract expired events based on
> the clock and these event attributes.
>
>
> laune wrote
>>
>> Your condition
>>    Event()
>> is just a test for a fact of type Event() being in WM, and it doesn't
>> care for its timestamp and duration.
>>
>
> OK, so my Event() condition just matches on all events, without any
> reference to the internal clock or the Event() @timestamp.  That I think I
> get.
>
>
> laune wrote
>>
>> For relating (real or psudo) with your events' times, look at
>> window:time, timer() and the aforementioned temporal ops.
>>
>
> I thought I'd looked at these, but I've revisited them at your suggestion.
> So I tried the following:
>
> Setup as before: pseudo clock, STREAM processing etc.
>
> I modified my rule match as follows:
>
> rule "events"
> when
> 	e : Event() over window:time(1s)
> then
> 	System.out.println(e.name);
> end
>
> This I understand to mean match on any event in the last one second.  That
> is, any event with (timestamp + duration) that overlapped the last second.
>
> - I create and  assert an event timestamped at 0, duration 1000ms
> - I advance the (pseudo) clock 5 seconds
> - I fireAllRules()
>
> Yet I still see the event matching the rule.  So I still appear to have a
> fundamental misunderstanding of how Fusion deals with time.  Do I need a
> heartbeat event stream to compare my real events to? Does the pseudo clock
> work differently to the real one (and does it automatically start at 0)?  Is
> there a difference between @timestamp and insertion time?  Perhaps a really,
> REALLY simple example showing Fusion's automatic retraction of events -
> without recourse to additional facts - would help me get it.
>
> Some background may help.  The domain I'm dealing with is a social TV
> schedule.  Programs are events with start and duration that are
> bulk-inserted as the schedule is released (say, weekly).  As people log in
> (a point event) they are informed what programs are currently showing.  As
> programs expire (i.e. start-time + duration is in the past) they are
> automatically retracted.  This last bit was what I was trying to emulate as
> a proof-of-concept.
>
> Any help you (or anyone!) can give would really be appreciated.
>
> Thanks,
> Robin
>
>
> --
> View this message in context:
> http://drools.46999.n3.nabble.com/Problem-with-simple-Fusion-test-case-tp3914358p3916643.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
>