[rules-users] Does JIT give me a hard time?

[Mark Proctor]

Mario will answer more in full.

The MVEL JIT is new to 5.4, and has had some teething problems. Mario did add the ability to turn JIT off, but I"m not sure if that's in 5.4 or not.

The best thing to do is provide test cases, and we'll make sure all JIT issues are fixed for 5.5

Mark
On 28 Sep 2012, at 00:17, wasperen <willem at van.asperen.org> wrote:

> Hi,
> 
> I have been using Drools for some years now and really happy with it!
> 
> But I am struggling now with the 5.4 version. It seems that the JIT compiler
> does not like me. For example, I have a rule that says:
> 
> rule "activate operations, for operator"
> 	when
> 		$worker : VCMShiftWorker( selectQuery == "operatorSelect" )
> 		$ea : ExecutableAction(
> 			action.subject.parentActionable != null,
> 			$worker.isUnderManagement( action.subject.parentActionable )
> 		)
> 		not RelevantExecutableAction(
> 			$worker;
> 			executableAction != $ea,
> 			executableAction.priority > $ea.priority ||
> 			(executableAction.priority == $ea.priority && executableAction.workTime >
> $ea.workTime) ||
> 			(executableAction.priority == $ea.priority && executableAction.workTime
> == $workTime && $critical && ! executableAction.critical)
> 		)		
> 	then
> 		System.out.println($worker+" makes relevant :"+$ea);
> 		insert( new RelevantExecutableAction( $worker, $ea ) );
> end
> 
> When I run this, I get a Thread that tell me there is a NPE because $ea is
> null... So I had to re-write that same rule as
> 
> rule "activate operations, for operator"
> 	when
> 		$worker : VCMShiftWorker( selectQuery == "operatorSelect" )
> 		$ea : ExecutableAction(
> 			$prio : priority,
> 			$workTime : workTime,
> 			$critical : critical,
> 			action.subject.parentActionable != null,
> 			$worker.isUnderManagement( action.subject.parentActionable )
> 		)
> 		not RelevantExecutableAction(
> 			$worker;
> 			executableAction != $ea,
> 			executableAction.priority > $priority ||
> 			(executableAction.priority == $priority &&
> executableAction.workTime.compareTo($workTime) > 0) ||
> 			(executableAction.priority == $priority && executableAction.workTime ==
> $workTime && $critical && ! executableAction.critical)
> 		)		
> 	then
> 		System.out.println($worker+" makes relevant :"+$ea);
> 		insert( new RelevantExecutableAction( $worker, $ea ) );
> end
> 
> This works, but it's not nice.. And: why?
> 
> Also, I get errors like "java.lang.RuntimeException: Null accessor on node:
> tick", again from these separate threads. I think this means that MVEL
> cannot determine a getTick() from the fact that it should look at. In this
> case, this.tick does also not work; same thing.
> 
> I tried to switch JIT off by adding the -Dmvel.disable.jit=true property to
> the start-up, but that does not eliminate this issue.
> 
> A full stack-trace for the last error is as follows:
> 
> java.lang.RuntimeException: Null accessor on node: tick
> 	at
> org.drools.rule.constraint.ConditionAnalyzer.analyzeNode(ConditionAnalyzer.java:229)
> 	at
> org.drools.rule.constraint.ConditionAnalyzer.analyzeNode(ConditionAnalyzer.java:162)
> 	at
> org.drools.rule.constraint.ConditionAnalyzer.analyzeSingleCondition(ConditionAnalyzer.java:109)
> 	at
> org.drools.rule.constraint.ConditionAnalyzer.analyzeCondition(ConditionAnalyzer.java:102)
> 	at
> org.drools.rule.constraint.ConditionAnalyzer.analyzeCombinedCondition(ConditionAnalyzer.java:134)
> 	at
> org.drools.rule.constraint.ConditionAnalyzer.analyzeCondition(ConditionAnalyzer.java:94)
> 	at
> org.drools.rule.constraint.ConditionAnalyzer.analyzeCondition(ConditionAnalyzer.java:73)
> 	at
> org.drools.rule.constraint.MvelConditionEvaluator.getAnalyzedCondition(MvelConditionEvaluator.java:83)
> 	at
> org.drools.rule.constraint.MvelConstraint.executeJitting(MvelConstraint.java:214)
> 	at
> org.drools.rule.constraint.MvelConstraint.access$000(MvelConstraint.java:41)
> 	at org.drools.rule.constraint.MvelConstraint$1.run(MvelConstraint.java:201)
> 	at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> 	at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> 	at java.lang.Thread.run(Thread.java:722)
> 
> Another thing that fails to work in 5.4 is casting. For instance:
> ((Ship)mover).currentContainer does not compute. I get a Null accessor on
> mover...
> 
> Should I worry about this at all? Or is it just bad luck this time and will
> Drools just continue to process my rules?
> 
> To give you some context. We have built an agent based simulation engine,
> where the agents are "Smart". They can interact, responding to the Actions
> published by the agents in their environment by reasoning over them using
> Drools rules. Works really nice but I am getting worried by these exceptions
> now...
> 
> 
> 
> --
> View this message in context: http://drools.46999.n3.nabble.com/Does-JIT-give-me-a-hard-time-tp4020032.html
> Sent from the Drools: User forum mailing list archive at Nabble.com.
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users