Concerning point #1, I'm not sure I understand what you mean, I'm sorry, but might be connected to my last statement about "this approach would solve for "network delay issue" but will induce another problem (...)" Because basically with this approach I personally found that also: a. data is buffered and inserted in chronological order b. pseudoclock is advanced anyway after a "deathwatch" period, normally to activate negative patterns as you mention - thus at the same time discarding data if arriving after the deathwatch already triggered c. pseudoclock is advanced anyway to trigger timers of rules This is the part which gets complex and the reason behind I mentioned I do mostly same as code example linked. In my use case scenario, implementation of deathwatch + advance of pseudoclock anyway, do fit the bill; but of course result may vary depending case by case. Concerning point #2 in my use case timer of rules do work, even if I use pseudoclock. But again, result may differ depending on the rules specification, I suppose. Sorry I cannot be of more help, I thought worthy share my experience anyway because I felt was very similar scenario, and fortunately the system behaves as expected. Ciao MM On Wed, Jun 4, 2014 at 2:07 PM, SebastianStehle <mail2stehle(a)gmail.com&gt; wrote: > Thanks for your answer. > > We already use the pseudo-clock for running unit tests, but there might be > some other problems: > > 1. If you do not move forward step by step you can miss the exact times > when > using negative patterns. e.g. in my example you would need to step forward > with AdvanceTiem with about 100ms or 1sec or so. > > 2. We also use timers, this does not work with the pseudo clock as well, > same problem like above. > > In my understand the example should work, if not I dont see what the > @timestamp config is for. > > > > -- > View this message in context: > http://drools.46999.n3.nabble.com/Fusion-Insert-Events-with-timestamp-in-... > 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 >

We made another test with the pseudclock where we advanced the time after each measurement. Lets say we have the two measurements, the first at 10am and the second at 11am. Based on the rule before, you would expect that the rule fires at 10:10am because no other event is inserted. But what happens was that the rule is activated at 11am, because the clock has not been advanced in the meantime. This makes totally sense for me, so I thought you might need another thread or so.

If you implement it like this (pseudo-code), it works fine: session.insert(first); clock.advanceTime(first.getTime()); while (time < second.getTime()) { clock.advanceTime(100); time.add(100ms); } session.insert(second); clock.advanceTime(second.getTime());

What makes our scenario very complicated is that we mix realtime and pseudo-time a little bit. For example we have timers that trigger at midnight or so (in realtime) and we have measurmenets with a delay of some seconds, where we need a pseudoclock. I have no real idea how this can be realized, but I still wonder, what @timestamp is for, if it cannot combined with the normal clock.

-- View this message in context: http://drools.46999.n3.nabble.com/Fusion-Insert-Events-with-timestamp-in-... 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