[JBoss JIRA] Created: (JBRULES-3074) Null pointer at org.drools.time.impl.JDKTimerService.removeJob(JDKTimerService.java:103)
by Richard Ambridge (JIRA)
Null pointer at org.drools.time.impl.JDKTimerService.removeJob(JDKTimerService.java:103)
-----------------------------------------------------------------------------------------
Key: JBRULES-3074
URL: https://issues.jboss.org/browse/JBRULES-3074
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-core
Affects Versions: 5.1.1.FINAL
Environment: Ubuntu
Reporter: Richard Ambridge
Assignee: Mark Proctor
Priority: Blocker
Attachments: DroolsRuleTest.java, Item.java, rule1.drl
Using drools with time based rules and saliance, the saliance is not used when firing the rules
This only happens when multiple objects update at the same time.
e.g. Rule 1 is
salience 1000
dialect "mvel"
when
$i : Item(val==10)
Item(val==11, this after [0s, 1m] $i)
Rule 2 is
salience 1000
dialect "mvel"
when
$i : Item(val==10)
not( Item(val==11, this after [0s,1m] $i))
Rule3 is
salience 100
when
$i : Item(val==11)
Then we insert 3 items with val==10
Rule2 is activated 3 times...
Then we insert an item with val==11
Note, with a val==10 and val==11 in the memory, Rule 1 will activate, and Rule 3 will activate
However, Rule1 should fire first.. as its saliance is high
For the first item it does, but then the Rule 3 fires before 2nd item does.
Audit log is attached, but summary is
Object inserted (1), Item: val==10
Activation created: Rule 2 (1)
Object inserted (2), Item: val==10
Activation created: Rule 2 (2)
Object inserted (3), Item: val==10
Activation created: Rule 2 (3)
Object inserted (4), Item: val==11
Activation created: Rule 1 (1)
Activation created: Rule 1 (2)
Activation created: Rule 1 (3)
Activation created: Rule 3 (4)
Activation cancelled: Rule 2 (1)
Activation cancelled: Rule 2 (2)
Activation cancelled: Rule 2 (3)
.. here we have 4 activations, 3 for Rule1 (saliance 1000), 1 for Rule3(saliance 100)
Activation executed Rule 1 (1)
Activation executed Rule 3 (4) //WRONG
Activation cancelled: Rule 1 (2)
Activation cancelled: Rule 1 (3)
Activation created: Rule 2 (2)
Activation created: Rule 2 (3)
Note, this works fine in Drools 5.0
In Drools 5.2.0 CR1 a null pointer is thrown (another issue will be logged for that)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] Created: (JBRULES-3113) MVEL accepts funny comparison and evaluates without apparent semantics
by Wolfgang Laun (JIRA)
MVEL accepts funny comparison and evaluates without apparent semantics
----------------------------------------------------------------------
Key: JBRULES-3113
URL: https://issues.jboss.org/browse/JBRULES-3113
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-compiler (expert)
Affects Versions: 5.2.0.Final
Reporter: Wolfgang Laun
Assignee: Mark Proctor
Fix For: 5.3.0.Beta1
Without "dialect 'mvel'", the funny expression in eval() is (correctly) refused by the compiler (" The operator == is undefined for the argument type(s) boolean, int"). Using MVEL, the rule compiles and fires, apparently with random values for $int3 and $long4:
test5 1 1 65536 4294967296
test5 1 1 65568 4294967296
test5 1 1 65552 4294967296
test5 1 1 65536 65536
test5 1 1 65568 65536
test5 1 1 65552 65536
test5 1 1 65536 65568
test5 1 1 65536 65552
test5 1 1 65568 65568
test5 1 1 65552 65568
test5 1 1 65568 65552
test5 1 1 65552 65552
=== DRL ===
dialect "mvel"
rule kickOff
when
then
insert( Integer.valueOf( 1 ) );
insert( Long.valueOf( 1 ) );
insert( Integer.valueOf( 65552 ) ); // 0x10010
insert( Long.valueOf( 65552 ) );
insert( Integer.valueOf( 65568 ) ); // 0x10020
insert( Long.valueOf( 65568 ) );
insert( Integer.valueOf( 65536 ) ); // 0x10000
insert( Long.valueOf( 65536L ) );
insert( Long.valueOf( 4294967296L ) ); // 0x100000000L
end
rule test5
salience 100
when
$n1: Integer( $int1: intValue == 1 )
$n2: Long ( $long2: longValue )
$n3: Integer( this != $n1, $int3: intValue )
$n4: Long ( this != $n2, $long4: longValue )
eval( $int1 == $long2 == $int3 == $long4 )
then
System.out.println( "test5 " + $int1 + " "
+ $long2 + " "
+ $int3 + " "
+ $long4 );
end
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] Created: (JBRULES-3096) Variable binding in DRL files not working as expected inside from accumulate CE
by Mauricio Salatino (JIRA)
Variable binding in DRL files not working as expected inside from accumulate CE
-------------------------------------------------------------------------------
Key: JBRULES-3096
URL: https://issues.jboss.org/browse/JBRULES-3096
Project: Drools
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Affects Versions: 5.2.0.CR1, 5.3.0.M1
Reporter: Mauricio Salatino
Assignee: Mark Proctor
Fix For: 5.2.0
Attachments: variableBindingInsideAcc.zip
This could be a grammar problem, it was working in 5.1.1 but now in 5.2.0.CR1 and in 5.3.0.SNAP is not working anymore.
I'm attaching a file with the following two rules (the second commented)
rule "test"
when
patient : Patient()
$count: Number() from accumulate (dog: Dog(patientId == patient.id), count(dog))
// this gives a weird problem about not finding the class called patient (lowercase)
then
System.out.println("Dogs: "+ $count);
end
/*rule "test2"
when
$patient : Patient()
$count: Number() from accumulate (dog: Dog(patientId == $patient.id), count(dog))
// this tries to resolve the $patient.id as the dog.id, not sure why
then
System.out.println("Dogs: "+ $count);
end*/
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] (JBRULES-3289) PackageBuilder.getErrors().toString() should use a clearer layout (indentation and empty lines)
by Geoffrey De Smet (Created) (JIRA)
PackageBuilder.getErrors().toString() should use a clearer layout (indentation and empty lines)
-----------------------------------------------------------------------------------------------
Key: JBRULES-3289
URL: https://issues.jboss.org/browse/JBRULES-3289
Project: Drools
Issue Type: Enhancement
Security Level: Public (Everyone can see)
Components: drools-compiler (expert)
Reporter: Geoffrey De Smet
Assignee: Edson Tirelli
Fix For: 5.4.0.Beta1
It's hard to read the compilation errors in drools (and parsing them in my head).
The main problem is parsing the points where the next compile error begins.
By adding some indentation and removing some confusing empty lines this can be made a lot clearer.
BEFORE:
{code}
Unable to resolve ObjectType 'NotExistingClass' : [Rule name='serviceLocationSpread']
Unable to Analyse Expression location == $location:
[Error: unable to resolve method using strict-mode: org.drools.planner.examples.machinereassignment.domain.MrProcessAssignment.$location()]
[Near : {... location == $location ....}]
^
[Line: 112, Column: 68] : [Rule name='serviceLocationSpread']
Rule Compilation error : [Rule name='serviceLocationSpread']
org/drools/planner/examples/machinereassignment/solver/Rule_serviceLocationSpread_503372c0945a4f2287a530f4ff3aee40.java (9:2095) : $location cannot be resolved
// 2 extra empty lines
{code}
AFTER (with indentation):
{code}
Unable to resolve ObjectType 'NotExistingClass' : [Rule name='serviceLocationSpread']
Unable to Analyse Expression location == $location:
[Error: unable to resolve method using strict-mode: org.drools.planner.examples.machinereassignment.domain.MrProcessAssignment.$location()]
[Near : {... location == $location ....}]
^
[Line: 112, Column: 68] : [Rule name='serviceLocationSpread']
Rule Compilation error : [Rule name='serviceLocationSpread']
org/drools/planner/examples/machinereassignment/solver/Rule_serviceLocationSpread_503372c0945a4f2287a530f4ff3aee40.java (9:2095) : $location cannot be resolved
{code}
Just compare those two. The second one is easier to read diagonally and understand what's going wrong.
It might be even better if the "Rule Compliation error" part comes first (following the context-first guideline):
So instead of:
{code}
Error A1
Error A1 details
Error A2
Error A2 details
Rule Compilation error A
Rule Compilation error A details
Error B1
Error B1 details
Error B2
Error B2 details
Rule Compilation error B
Rule Compilation error B details
{code}
We get:
{code}
Rule Compilation error A
Rule Compilation error A details
Error A1
Error A1 details
Error A2
Error A2 details
Rule Compilation error B
Rule Compilation error B details
Error B1
Error B1 details
Error B2
Error B2 details
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] (JBRULES-3286) org.drools.time.TimerService.scheduleJob(Job, JobContext, Trigger) suddenly requires non-null JobContext
by Richard Calmbach (Created) (JIRA)
org.drools.time.TimerService.scheduleJob(Job, JobContext, Trigger) suddenly requires non-null JobContext
--------------------------------------------------------------------------------------------------------
Key: JBRULES-3286
URL: https://issues.jboss.org/browse/JBRULES-3286
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-core (fusion)
Affects Versions: 5.3.0.Final
Reporter: Richard Calmbach
Assignee: Mark Proctor
See the forum reference above for context. As requested, this is the bug report for issue F3 in the post. The intro and description are copied from the original post:
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 F3:
It is debatable whether this is a bug, but it is a backward-compatibility breaking change. Previously, when scheduling a job with org.drools.time.TimerService.scheduleJob(Job job, JobContext ctx, Trigger trigger) (for both real-time and pseudo clock), you could pass a null JobContext (say, because you didn't need one), and it would work. However, in Drools 5.3.0, this causes a NullPointerException at:
org.drools.time.impl.DefaultTimerJobFactoryManager.createTimerJobInstance(Job, JobContext, Trigger, JobHandle, InternalSchedulerService) line: 25
I realize that if it's not in knowledge-api-<version>.jar, it's not an official API, but the available interfaces and classes in org.drools.time.** (as used in the Broker example) are *very* useful for test harnesses *and* for production code (for implementing dynamic timers, for instance). So, this is more of a heads-up: If you are suddenly getting an NPE, this might be the cause.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] (JBRULES-3284) Duplicate job scheduling in org.drools.time.impl.DefaultTimerJobInstance.call()
by Richard Calmbach (Created) (JIRA)
Duplicate job scheduling in org.drools.time.impl.DefaultTimerJobInstance.call()
-------------------------------------------------------------------------------
Key: JBRULES-3284
URL: https://issues.jboss.org/browse/JBRULES-3284
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-core (fusion)
Affects Versions: 5.3.0.Final
Reporter: Richard Calmbach
Assignee: Mark Proctor
See the forum reference above for context. As requested, this is the bug report for issue F1 in the post. The intro and description are copied from the original post:
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):
{code}
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 );
}
}
{code}
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():
{code}
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;
}
{code}
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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] (JBRULES-3285) NullPointerException in org.drools.time.impl.DefaultTimerJobInstance.compareTo(DefaultTimerJobInstance)
by Richard Calmbach (Created) (JIRA)
NullPointerException in org.drools.time.impl.DefaultTimerJobInstance.compareTo(DefaultTimerJobInstance)
-------------------------------------------------------------------------------------------------------
Key: JBRULES-3285
URL: https://issues.jboss.org/browse/JBRULES-3285
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-core (fusion)
Affects Versions: 5.3.0.Final
Reporter: Richard Calmbach
Assignee: Mark Proctor
See the forum reference above for context. As requested, this is the bug report for issue F2 in the post. The intro and description are copied from the original post:
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 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
PriorityQueue<E>.siftUpComparable(int, E) line: 582
PriorityQueue<E>.siftUp(int, E) line: 574
PriorityQueue<E>.offer(E) line: 274
PriorityQueue<E>.add(E) line: 251
PseudoClockScheduler.internalSchedule(TimerJobInstance) line: 136
PseudoClockScheduler.scheduleJob(Job, JobContext, Trigger) line: 126
ObjectTypeNode.assertObject(InternalFactHandle, PropagationContext, InternalWorkingMemory) line: 230
EntryPointNode.assertObject(InternalFactHandle, PropagationContext, ObjectTypeConf, InternalWorkingMemory) line: 244
NamedEntryPoint.insert(InternalFactHandle, Object, Rule, Activation, ObjectTypeConf) line: 330
NamedEntryPoint.insert(Object, boolean, boolean, Rule, Activation) line: 291
NamedEntryPoint.insert(Object) line: 116
NamedEntryPoint.insert(Object) line: 48
<my code calling into Drools>
Here is method org.drools.time.impl.DefaultTimerJobInstance.compareTo(DefaultTimerJobInstance):
{code}
public int compareTo(DefaultTimerJobInstance o) {
return this.trigger.hasNextFireTime().compareTo( o.getTrigger().hasNextFireTime() );
}
{code}
Essentially, this method calls java.util.Date.compareTo(Date) with a null argument, which, as documented, causes a NullPointerException. Sometimes, this.trigger.hasNextFireTime() already returns null, and then the NPE gets thrown in DefaultTimerJobInstance.compareTo() itself.
I've seen different stack traces leading to this NPE, so this must be affecting scheduling and job execution quite broadly.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months