No I don't modify any LoopDetectorEvent.Actually, in some situations the rule
fires even more than two times for some Sensors.
I don't use the logger. I just do System.out.println's to see when a rule
fires. . If you need any more info, then I will use the logger for you. What
information might
The loggers will show you why a rule activation was fired. It will tell you
which facts activate the rule, then you can reach new conclusions with that
information.
Greetings.
On Sun, Feb 6, 2011 at 2:02 PM, OlliSee o.ro...@seeburger.de wrote:
No I don't modify any LoopDetectorEvent.Actually,
Hello folks.
Got a new characteristic unveiled,...
if I have a rule like this (with Fusion in STREAM mode)...
(Sensor is a fact)
rule Test
timer(int: 7s 7s)
when
$sensor : Sensor()
Number($avg : doubleValue 0.0) from accumulate
are you updating or modifying any LoopDetectorEvent() event?
Greetings.
What did you see in the logger output?
On Fri, Feb 4, 2011 at 1:15 PM, OlliSee o.ro...@seeburger.de wrote:
Hello folks.
Got a new characteristic unveiled,...
if I have a rule like this (with Fusion in STREAM mode)...
On 10/12/2010 23:00, Mark Proctor wrote:
On 10/12/2010 08:44, Wolfgang Laun wrote:
Done. There are two FIXME-tests at the end, one for timer() + not; the other
one
demonstrating that drools.halt() from a rule with a timer() doesn't
terminate the
session - it also keeps firing. Notice that
Done. There are two FIXME-tests at the end, one for timer() + not; the other one
demonstrating that drools.halt() from a rule with a timer() doesn't
terminate the
session - it also keeps firing. Notice that even with no timer() on
the halt rule
but with another rule having a periodic timer
On 10/12/2010 08:44, Wolfgang Laun wrote:
Done. There are two FIXME-tests at the end, one for timer() + not; the other
one
demonstrating that drools.halt() from a rule with a timer() doesn't
terminate the
session - it also keeps firing. Notice that even with no timer() on
the halt rule
but
Ooh, it seems Eclipse outwitted me once again. But I think I made it on the
2nd try...
Sorry
W
PS:
(1) A decision on the matter of DSL variables would be appreciated. I'm
currently
developing a non-trivial DSL, and learning a lot about what's needed for a
*real world *application. Most
Hello there.
I seem to have trouble with the timer operator which is documented to have
superseded the duration operator for use in the rule body. I might have
something to do with the not operator I use in my rule.
Scenario: A is a fact, B is an event
When I write something like this
rule
I ran a few more tests and it seems that duration is also not capable of
achieving the expected results.
If you have a lot of different A objects in the example, and a few more
complex conditions in the LHS, the rule will only fire for a few A objects,
omitting the rest, when the duration timer
On 09/12/2010 12:30, OlliSee wrote:
Hello there.
I seem to have trouble with the timer operator which is documented to have
superseded the duration operator for use in the rule body. I might have
something to do with the not operator I use in my rule.
Scenario: A is a fact, B is an event
Thanks,
unfortunately not working, either.
Maybe it will help, if I describe the scenario more detailed.
I have three A facts inserted at the beginning.
Then the rule fires the first time after 5 seconds for every A fact and
inserts the B events.
Then I retract ONE of the B events, but the rule
I can confirm that the timer rule continues to fire
- if the condition contains a not CE
- even after the not CE should return false
Repeating timer firing stops for positive CEs turning to false.
-W
On 9 December 2010 15:06, OlliSee o.ro...@seeburger.de wrote:
Thanks,
unfortunately not
On 09/12/2010 14:50, Wolfgang Laun wrote:
I can confirm that the timer rule continues to fire
- if the condition contains a not CE
- even after the not CE should return false
Repeating timer firing stops for positive CEs turning to false.
sounds like a bug :(
Wolfgang, could you commit your
14 matches
Mail list logo
