11:29 a.m.
Hi,
I am working on an existing drools project. We have a lot of rules with
"after" or "not after" relationships.
One of the problems I run into is when updating the rules. At the moment a
new session will be created and all facts are inserted from the old to the
new session. But something does not work in the scenario. To reproduce the
problem I made a simple test with the following rule:
rule "not after"
when
$message : DroolsSimulationMessage(value == 1) not
(DroolsSimulationMessage(value == 2, this after [1s, 10s] $message))
then
end
I inserted an event with a timestamp 5 seconds in the past and I expect the
rule to be activated 5 seconds after the event was inserted. But in my
scenario it does not work, the rule is activated after 10 seconds. This is a
very important point to make the current update progress work. Should it
work and if not is there a better way to realize rule-updates?
Thanks you in advance,
Sebastian
--
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.
11:32 a.m.
I have forgotten to mention that the drools version is 5.5.0.Final, the test
is running in stream mode with a realtime 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.
11:54 a.m.
On 4 June 2014 11:32, SebastianStehle <mail2stehle(a)gmail.com> wrote:
I have forgotten to mention that the drools version is 5.5.0.Final,
the test
is running in stream mode with a realtime clock.
That's just the point. In real time, the past is past. For re-living the past
with a different set of rules, you should consider using a pseudo-clock.
Now time is under the control of the program, and you can replay the
past and then slip into "second-hand real-time mode".
-W
--
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
11:59 a.m.
I see that the update process is not optimal, but can you tell me if my
simple example should work or not?
We get measurements from sensors. Because of network delay and other
intermediate processes the timestamp of the measurements can be some seconds
behind the time of the insert. In this case the rules with after would not
work correctly as well.
I am new to drools, so there is a high chance that I make some mistakes.
--
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.
1:54 p.m.
Hi Sebastian,
As per your last email, your use case sounds very similar to my use case
scenario and I would second the suggestion from Wolfgang, switch from
realtime to pseudoclock may help.
I think the thread "[rules-users] Question about Fusion pseudoclock" in the
mailing list could help, and in my use case scenario I found the following
code example *extremely* valuable because I do mostly same
https://github.com/droolsjbpm/droolsjbpm-contributed-experiments/blob/mas...
I hope this helps you too.
This approach would solve for "network delay issue" but will induce another
problem, in case "network" never restores or delay gets outrageous.
Ciao
MM
On 4 Jun 2014 12:00, "SebastianStehle" <mail2stehle(a)gmail.com> wrote:
I see that the update process is not optimal, but can you tell me if
my
simple example should work or not?
We get measurements from sensors. Because of network delay and other
intermediate processes the timestamp of the measurements can be some
seconds
behind the time of the insert. In this case the rules with after would not
work correctly as well.
I am new to drools, so there is a high chance that I make some mistakes.
--
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
2:07 p.m.
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.
3:55 p.m.
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>
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
4 p.m.
Errata Corrige: "Because basically with this approach I personally found
that also *you have to*:"
I missed the *you have to* bit, sorry.
On Wed, Jun 4, 2014 at 3:55 PM, Matteo Mortari <matteo.mortari(a)gmail.com>
wrote:
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>
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
>
4:32 p.m.
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.
5:09 p.m.
On 04/06/2014, SebastianStehle <mail2stehle(a)gmail.com> wrote:
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.
Absolutely.
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());
Right, this should take care of the timers.
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.
The time of measurements is one progress of time, and when you need a
midnight event, you should ask one of the measurement providers. If
midnight is a more or less arbitrary point in that progress of time,
you can use your local clock.
There is an European norm that deals with the reliability of networks.
If you have to expect delays, you may have to detect them, and decide
what counter-action to employ.
IIRC, at the start if this thread there was the issue of updating
rules. There is the option of changing the rules "on the fly", without
creating a new session. And there may be a different approach,
deriving "state" from a sequence of events, rather than trying to
keep the sequence with its timestamps - but this depends on what the
events signify.
-W
--
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
4:59 p.m.
On 04/06/2014, SebastianStehle <mail2stehle(a)gmail.com> wrote:
I see that the update process is not optimal, but can you tell me if
my
simple example should work or not?
We get measurements from sensors. Because of network delay and other
intermediate processes the timestamp of the measurements can be some
seconds
behind the time of the insert.
How can this be? t(measurement) < t(insert), which is "before".
As long as network delay is uniform for all sources, it doesn't
matter. If there are different sensor positions with data being
relayed over different links, delays may depend on the source. But in
this case, you are up the creek anyway.
-W
In this case the rules with after would not
work correctly as well.
I am new to drools, so there is a high chance that I make some mistakes.
--
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
5:04 p.m.
Yes, t(measurment) < t(insert). The sensors communicate with the server with
3g, which might be slow in some situations.
I simplify my question: Can I use @timestamp with realtime-clocks?
--
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.
5:11 p.m.
A @timestamp is just an increasing sequence of values - it has no
other implications. Cloud vs. stream mode determines how these
values should be ordered on insertion.
-W
On 04/06/2014, SebastianStehle <mail2stehle(a)gmail.com> wrote:
Yes, t(measurment) < t(insert). The sensors communicate with the
server
with
3g, which might be slow in some situations.
I simplify my question: Can I use @timestamp with realtime-clocks?
--
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
5:33 p.m.
I am really thankful about your patience. Please do not focus on the network
delay so far, there are other processes, which can cause the delay. Perhaps
I will find a better solution here, but I would prefer to understand what is
happing first.
Can you explain me the following examples?
1. First example:
LHS: $e: Message (Message(this after [0, 10sec] $e), where Message has an
@timestamp
1.1.
insert(new Message(NOW().subtract(5sec))); <-- 11am
wait(6sec);
insert(new Message(NOW()));
// NOT Activated
1.2.
insert(new Message(NOW().subtract(5sec))); <-- 11am
wait(2sec);
insert(new Message(NOW()));
// Activated at 11:05am
2. First example:
LHS: $e: Message not (Message(this after [0, 10sec] $e), where Message has
an @timestamp
insert(new Message(NOW().subtract(5sec))); <-- 11am
// Activated at 11:10am
Example 1.1 and 1.2 works as expected and my timestamp is respected but not
example 2.
Can you give me some hints about the "hot-deployment" for rules?
--
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.
10:05 a.m.
I realized that there are some mistakes in my previous post with the times:
1. First example:
LHS: $e: Message (Message(this after [0, 10sec] $e), where Message has an
@timestamp
1.1.
insert(new Message(NOW().subtract(5sec))); <-- 11:00:00am
wait(6sec);
insert(new Message(NOW()));
// NOT Activated
1.2.
insert(new Message(NOW().subtract(5sec))); <-- 11:00:00am
wait(2sec);
insert(new Message(NOW()));
// Activated at 11:00:05am
2. First example:
LHS: $e: Message not (Message(this after [0, 10sec] $e), where Message has
an @timestamp
insert(new Message(NOW().subtract(5sec))); <-- 11:00:00am
// Activated at 11:00:10am
Has anybody an idea with example #2 is not working?
--
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.
3605
days inactive
3618
days old
14 comments
3 participants
participants (3)
-
Matteo Mortari -
SebastianStehle -
Wolfgang Laun