Re: [rules-users] Bugs in Drools 5.3.0 break Fusion event processing
Thanks Richard, I will fix them for the next release. Edson 2011/11/9 Richard Calmbach rcalm...@gmail.com Edson: Thanks for the quick reply. I created these JIRA issues: F1: Duplicate job scheduling in org.drools.time.impl.DefaultTimerJobInstance.call() - https://issues.jboss.org/browse/JBRULES-3284 F2: NullPointerException in org.drools.time.impl.DefaultTimerJobInstance.compareTo(DefaultTimerJobInstance) - https://issues.jboss.org/browse/JBRULES-3285 F3: org.drools.time.TimerService.scheduleJob(Job, JobContext, Trigger) suddenly requires non-null JobContext - https://issues.jboss.org/browse/JBRULES-3286 While you are working on the event scheduling system, you may also want to look at these two earlier bug reports for Drools 5.2.0: Long.MAX_VALUE duration for A and not(B after A) type rules causes invalid session clock time in rule RHS when running with pseudo clock - https://issues.jboss.org/browse/JBRULES-3100 A and not(B after A) type rules don't fire when session clock has negative values (pre Unix epoch) - https://issues.jboss.org/browse/JBRULES-3103 I have not checked their status in Drools 5.3.0, but the description should tell you whether they still apply. FWIW, among all of these, F2 (JBRULES-3285) has the highest priority (as it's breaking my unit tests), followed by F1 (JBRULES-3284). Thanks! Vincent: Yes, I think there is risk. Even if you don't use jobs explicitly, Drools uses the same event scheduling system for both internal events and application-defined events and jobs. The main problem is this: How do you establish correctness of your code and the overall system? Well, you make sure your unit tests and functional tests pass. As it stands, I cannot get my tests to pass with Drools 5.3.0, so I cannot put Drools 5.3.0 in production. No matter which version you use, only good test coverage will give you the assurance that your system is functioning properly. I encourage you to try out Drools 5.3.0 (in a test environment) and to report any issues you run into. It can only help make Drools better. 2011/11/9 Vincent LEGENDRE vincent.legen...@eurodecision.com Just wondering : does these problems happends because you use clocks and jobs, or is it general to fusion 5.3 ? Did not migrate my project on 5.3 for now. So do you think there is a risk, knowing that I only use very basic fusion features ? -- *De: *Edson Tirelli ed.tire...@gmail.com *À: *Rules Users List rules-users@lists.jboss.org *Envoyé: *Mercredi 9 Novembre 2011 14:53:00 *Objet: *Re: [rules-users] Bugs in Drools 5.3.0 break Fusion event processing Richard, This is great info. Yes, please open JIRA's for all 3 issues and we will make sure this is fixed for the next release. Thank you, Edson ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users -- Edson Tirelli JBoss Drools Core Development JBoss by Red Hat @ www.jboss.com ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Bugs in Drools 5.3.0 break Fusion event processing
Richard,
This is great info. Yes, please open JIRA's for all 3 issues and we will
make sure this is fixed for the next release.
Thank you,
Edson
2011/11/9 Richard Calmbach rcalm...@gmail.com
I am making extensive use of the event processing features of the Drools
rule engine. Upgrading from Drools 5.2.0.Final to Drools 5.3.0.Final broke
47 of my unit tests and also broke my functional tests. There seem to be
multiple changes in Drools 5.3.0 that cause incorrect behavior and/or break
backward compatibility. Here are the results of my investigation so far.
Issue F1:
While tracking down the failures of my unit tests, I experimented with the
Broker example, and while probably not finding the root cause of the broken
unit tests, I nonetheless came across what clearly seems to be incorrect
behavior in the DefaultTimerJobInstance.call() method. The bug only reveals
itself after all input has been processed, so it is masked by the fact that
running the Broker demo through the entire sequence in stocktickstream.dat
(1100 lines) takes a long time. In order to reveal the problem more
quickly, run the demo with only the first 14 lines in stocktickstream.dat.
Do so for both the 5.2.0 Broker demo (against Drools 5.2.0) and the 5.3.0
Broker demo (against Drools 5.3.0). The Broker example code in both
versions is identical, so only the Drools-internal code changes matter.
When running the 5.2.0 Broker demo to the end, you get one
java.text.ParseException (given the structure of the example code, that's
expected, albeit not elegant, and not the focus of our investigation). In
particular, no matter how many lines stocktickstream.dat contains, you
always get exactly one ParseException at the end.
Contrast this with running the 5.3.0 Broker demo: At the end you get N
occurrences of java.text.ParseException, where N is the number of lines in
stocktickstream.dat. So for 14 lines you get 14 occurrences of
ParseException. Looking at two specific methods shows us why:
Method
org.drools.examples.broker.events.EventFeeder.FeedJob.execute(JobContext):
public void execute(JobContext context) {
this.sink.receive( ((FeedContext) context).event );
if ( this.source.hasNext() ) {
((FeedContext) context).setEvent( this.source.getNext() );
this.trigger.setNextFireTime( ((FeedContext)
context).getEvent().getDate() );
clock.scheduleJob( this,
context,
trigger );
}
}
Note in particular how this method already takes care of scheduling the
next job execution by updating the next fire time of the job's existing
FeedTrigger instance. Unfortunately, in Drools 5.3.0,
DefaultTimerJobInstance.call() does a duplicate scheduling of the same job:
Method org.drools.time.impl.DefaultTimerJobInstance.call():
public Void call() throws Exception {
this.trigger.nextFireTime(); // need to pop
if ( handle.isCancel() ) {
return null;
}
this.job.execute( this.ctx );
if ( handle.isCancel() ) {
return null;
}
// our triggers allow for flexible rescheduling
Date date = this.trigger.hasNextFireTime();
if ( date != null ) {
scheduler.internalSchedule( this );
}
return null;
}
So, every job is duplicated and that's why there are 2*N calls to
org.drools.examples.broker.events.StockTickPersister.load() instead of N.
I think the rescheduling inside DefaultTimerJobInstance.call() is
incorrect. For one, it breaks backward compatibility, and it is unexpected.
The job should be in charge of deciding whether there is another job to
schedule or what to do. Implicitly scheduling the next job just by updating
the trigger time is a little too much magic.
Issue F2:
This is the bug that causes my unit tests to fail. I have not pinpointed
the root cause, but it seems to have to do with the event scheduling Drools
does as part of its job execution mechanism. Its symptom is a
NullPointerException during insertion of an event. What makes it so tricky
is that with the out-of-the-box configuration, Drools catches such
exceptions in org.drools.time.impl.PseudoClockScheduler.runCallBacks() and
passes them to the aptly named DoNothingSystemEventListener, which
literally does nothing, not so much as logging (the methods are empty). So
you don't actually know that the event insertion failed, you only wonder
why your mock WorkingMemoryEventListener is telling you that your
expectations are not met. The stack trace (as copied from the Eclipse Debug
view, hence the unusual formatting) inside Drools is:
Date.getMillisOf(Date) line: 939
Date.compareTo(Date) line: 959
DefaultTimerJobInstance.compareTo(DefaultTimerJobInstance) line: 38
DefaultTimerJobInstance.compareTo(Object) line: 13
Re: [rules-users] Bugs in Drools 5.3.0 break Fusion event processing
Just wondering : does these problems happends because you use clocks and jobs,
or is it general to fusion 5.3 ?
Did not migrate my project on 5.3 for now.
So do you think there is a risk, knowing that I only use very basic fusion
features ?
- Mail original -
De: Edson Tirelli ed.tire...@gmail.com
À: Rules Users List rules-users@lists.jboss.org
Envoyé: Mercredi 9 Novembre 2011 14:53:00
Objet: Re: [rules-users] Bugs in Drools 5.3.0 break Fusion event processing
Richard,
This is great info. Yes, please open JIRA's for all 3 issues and we will make
sure this is fixed for the next release.
Thank you,
Edson
2011/11/9 Richard Calmbach rcalm...@gmail.com
I am making extensive use of the event processing features of the Drools rule
engine. Upgrading from Drools 5.2.0.Final to Drools 5.3.0.Final broke 47 of my
unit tests and also broke my functional tests. There seem to be multiple
changes in Drools 5.3.0 that cause incorrect behavior and/or break backward
compatibility. Here are the results of my investigation so far.
Issue F1:
While tracking down the failures of my unit tests, I experimented with the
Broker example, and while probably not finding the root cause of the broken
unit tests, I nonetheless came across what clearly seems to be incorrect
behavior in the DefaultTimerJobInstance.call() method. The bug only reveals
itself after all input has been processed, so it is masked by the fact that
running the Broker demo through the entire sequence in stocktickstream.dat
(1100 lines) takes a long time. In order to reveal the problem more quickly,
run the demo with only the first 14 lines in stocktickstream.dat. Do so for
both the 5.2.0 Broker demo (against Drools 5.2.0) and the 5.3.0 Broker demo
(against Drools 5.3.0). The Broker example code in both versions is identical,
so only the Drools-internal code changes matter.
When running the 5.2.0 Broker demo to the end, you get one
java.text.ParseException (given the structure of the example code, that's
expected, albeit not elegant, and not the focus of our investigation). In
particular, no matter how many lines stocktickstream.dat contains, you always
get exactly one ParseException at the end.
Contrast this with running the 5.3.0 Broker demo: At the end you get N
occurrences of java.text.ParseException, where N is the number of lines in
stocktickstream.dat. So for 14 lines you get 14 occurrences of ParseException.
Looking at two specific methods shows us why:
Method
org.drools.examples.broker.events.EventFeeder.FeedJob.execute(JobContext):
public void execute(JobContext context) {
this.sink.receive( ((FeedContext) context).event );
if ( this.source.hasNext() ) {
((FeedContext) context).setEvent( this.source.getNext() );
this.trigger.setNextFireTime( ((FeedContext) context).getEvent().getDate() );
clock.scheduleJob( this,
context,
trigger );
}
}
Note in particular how this method already takes care of scheduling the next
job execution by updating the next fire time of the job's existing FeedTrigger
instance. Unfortunately, in Drools 5.3.0, DefaultTimerJobInstance.call() does a
duplicate scheduling of the same job:
Method org.drools.time.impl.DefaultTimerJobInstance.call():
public Void call() throws Exception {
this.trigger.nextFireTime(); // need to pop
if ( handle.isCancel() ) {
return null;
}
this.job.execute( this.ctx );
if ( handle.isCancel() ) {
return null;
}
// our triggers allow for flexible rescheduling
Date date = this.trigger.hasNextFireTime();
if ( date != null ) {
scheduler.internalSchedule( this );
}
return null;
}
So, every job is duplicated and that's why there are 2*N calls to
org.drools.examples.broker.events.StockTickPersister.load() instead of N.
I think the rescheduling inside DefaultTimerJobInstance.call() is incorrect.
For one, it breaks backward compatibility, and it is unexpected. The job should
be in charge of deciding whether there is another job to schedule or what to
do. Implicitly scheduling the next job just by updating the trigger time is a
little too much magic.
Issue F2:
This is the bug that causes my unit tests to fail. I have not pinpointed the
root cause, but it seems to have to do with the event scheduling Drools does as
part of its job execution mechanism. Its symptom is a NullPointerException
during insertion of an event. What makes it so tricky is that with the
out-of-the-box configuration, Drools catches such exceptions in
org.drools.time.impl.PseudoClockScheduler.runCallBacks() and passes them to the
aptly named DoNothingSystemEventListener, which literally does nothing, not
so much as logging (the methods are empty). So you don't actually know that the
event insertion failed, you only wonder why your mock
WorkingMemoryEventListener is telling you that your expectations are not met.
The stack trace (as copied from the Eclipse Debug view, hence the unusual
formatting) inside Drools is:
Date.getMillisOf(Date) line: 939
Re: [rules-users] Bugs in Drools 5.3.0 break Fusion event processing
Edson: Thanks for the quick reply. I created these JIRA issues: F1: Duplicate job scheduling in org.drools.time.impl.DefaultTimerJobInstance.call() - https://issues.jboss.org/browse/JBRULES-3284 F2: NullPointerException in org.drools.time.impl.DefaultTimerJobInstance.compareTo(DefaultTimerJobInstance) - https://issues.jboss.org/browse/JBRULES-3285 F3: org.drools.time.TimerService.scheduleJob(Job, JobContext, Trigger) suddenly requires non-null JobContext - https://issues.jboss.org/browse/JBRULES-3286 While you are working on the event scheduling system, you may also want to look at these two earlier bug reports for Drools 5.2.0: Long.MAX_VALUE duration for A and not(B after A) type rules causes invalid session clock time in rule RHS when running with pseudo clock - https://issues.jboss.org/browse/JBRULES-3100 A and not(B after A) type rules don't fire when session clock has negative values (pre Unix epoch) - https://issues.jboss.org/browse/JBRULES-3103 I have not checked their status in Drools 5.3.0, but the description should tell you whether they still apply. FWIW, among all of these, F2 (JBRULES-3285) has the highest priority (as it's breaking my unit tests), followed by F1 (JBRULES-3284). Thanks! Vincent: Yes, I think there is risk. Even if you don't use jobs explicitly, Drools uses the same event scheduling system for both internal events and application-defined events and jobs. The main problem is this: How do you establish correctness of your code and the overall system? Well, you make sure your unit tests and functional tests pass. As it stands, I cannot get my tests to pass with Drools 5.3.0, so I cannot put Drools 5.3.0 in production. No matter which version you use, only good test coverage will give you the assurance that your system is functioning properly. I encourage you to try out Drools 5.3.0 (in a test environment) and to report any issues you run into. It can only help make Drools better. 2011/11/9 Vincent LEGENDRE vincent.legen...@eurodecision.com Just wondering : does these problems happends because you use clocks and jobs, or is it general to fusion 5.3 ? Did not migrate my project on 5.3 for now. So do you think there is a risk, knowing that I only use very basic fusion features ? -- *De: *Edson Tirelli ed.tire...@gmail.com *À: *Rules Users List rules-users@lists.jboss.org *Envoyé: *Mercredi 9 Novembre 2011 14:53:00 *Objet: *Re: [rules-users] Bugs in Drools 5.3.0 break Fusion event processing Richard, This is great info. Yes, please open JIRA's for all 3 issues and we will make sure this is fixed for the next release. Thank you, Edson ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
[rules-users] Bugs in Drools 5.3.0 break Fusion event processing
I am making extensive use of the event processing features of the Drools
rule engine. Upgrading from Drools 5.2.0.Final to Drools 5.3.0.Final broke
47 of my unit tests and also broke my functional tests. There seem to be
multiple changes in Drools 5.3.0 that cause incorrect behavior and/or break
backward compatibility. Here are the results of my investigation so far.
Issue F1:
While tracking down the failures of my unit tests, I experimented with the
Broker example, and while probably not finding the root cause of the broken
unit tests, I nonetheless came across what clearly seems to be incorrect
behavior in the DefaultTimerJobInstance.call() method. The bug only reveals
itself after all input has been processed, so it is masked by the fact that
running the Broker demo through the entire sequence in stocktickstream.dat
(1100 lines) takes a long time. In order to reveal the problem more
quickly, run the demo with only the first 14 lines in stocktickstream.dat.
Do so for both the 5.2.0 Broker demo (against Drools 5.2.0) and the 5.3.0
Broker demo (against Drools 5.3.0). The Broker example code in both
versions is identical, so only the Drools-internal code changes matter.
When running the 5.2.0 Broker demo to the end, you get one
java.text.ParseException (given the structure of the example code, that's
expected, albeit not elegant, and not the focus of our investigation). In
particular, no matter how many lines stocktickstream.dat contains, you
always get exactly one ParseException at the end.
Contrast this with running the 5.3.0 Broker demo: At the end you get N
occurrences of java.text.ParseException, where N is the number of lines in
stocktickstream.dat. So for 14 lines you get 14 occurrences of
ParseException. Looking at two specific methods shows us why:
Method
org.drools.examples.broker.events.EventFeeder.FeedJob.execute(JobContext):
public void execute(JobContext context) {
this.sink.receive( ((FeedContext) context).event );
if ( this.source.hasNext() ) {
((FeedContext) context).setEvent( this.source.getNext() );
this.trigger.setNextFireTime( ((FeedContext)
context).getEvent().getDate() );
clock.scheduleJob( this,
context,
trigger );
}
}
Note in particular how this method already takes care of scheduling the
next job execution by updating the next fire time of the job's existing
FeedTrigger instance. Unfortunately, in Drools 5.3.0,
DefaultTimerJobInstance.call() does a duplicate scheduling of the same job:
Method org.drools.time.impl.DefaultTimerJobInstance.call():
public Void call() throws Exception {
this.trigger.nextFireTime(); // need to pop
if ( handle.isCancel() ) {
return null;
}
this.job.execute( this.ctx );
if ( handle.isCancel() ) {
return null;
}
// our triggers allow for flexible rescheduling
Date date = this.trigger.hasNextFireTime();
if ( date != null ) {
scheduler.internalSchedule( this );
}
return null;
}
So, every job is duplicated and that's why there are 2*N calls to
org.drools.examples.broker.events.StockTickPersister.load() instead of N.
I think the rescheduling inside DefaultTimerJobInstance.call() is
incorrect. For one, it breaks backward compatibility, and it is unexpected.
The job should be in charge of deciding whether there is another job to
schedule or what to do. Implicitly scheduling the next job just by updating
the trigger time is a little too much magic.
Issue F2:
This is the bug that causes my unit tests to fail. I have not pinpointed
the root cause, but it seems to have to do with the event scheduling Drools
does as part of its job execution mechanism. Its symptom is a
NullPointerException during insertion of an event. What makes it so tricky
is that with the out-of-the-box configuration, Drools catches such
exceptions in org.drools.time.impl.PseudoClockScheduler.runCallBacks() and
passes them to the aptly named DoNothingSystemEventListener, which
literally does nothing, not so much as logging (the methods are empty). So
you don't actually know that the event insertion failed, you only wonder
why your mock WorkingMemoryEventListener is telling you that your
expectations are not met. The stack trace (as copied from the Eclipse Debug
view, hence the unusual formatting) inside Drools is:
Date.getMillisOf(Date) line: 939
Date.compareTo(Date) line: 959
DefaultTimerJobInstance.compareTo(DefaultTimerJobInstance) line: 38
DefaultTimerJobInstance.compareTo(Object) line: 13
PriorityQueueE.siftUpComparable(int, E) line: 582
PriorityQueueE.siftUp(int, E) line: 574
PriorityQueueE.offer(E) line: 274
PriorityQueueE.add(E) line: 251
PseudoClockScheduler.internalSchedule(TimerJobInstance) line: 136
PseudoClockScheduler.scheduleJob(Job, JobContext, Trigger) line: 126
