Rule injected into sun.reflect.MethodAccessorGenerator.generateMethod fires recursively with setTriggering(false);

johara Sep 3, 2013 5:27 AM

When a rule is injected into sun.reflect.MethodAccessorGenerator.generateMethod() it is fired recursively, even when setTriggering(false) is called in the rule.

e.g.

RULE recursive rule
CLASS sun.reflect.MethodAccessorGenerator
METHOD generateMethod
AT ENTRY
IF TRUE
DO setTriggering(false);
traceln("recursive rule fired!");
ENDRULE

Note from Andrew Dinn:

"...The recursive triggering mechanism works by inhibiting the callout from a trigger method to the rule engine at the point of entry into the rule engine. However, Byteman needs to use some apparatus inside the triggering code to switch on that inhibiting mechanism. So, there will always be some elements of the runtime which Byteman needs to do this job and those cannot be the target for an injected rule without entering a recursive triggering loop and heading for a stack overflow.

So, why is sun.reflect.MethodAccessorGenerator implicated in this loop? Well, the rule engine normally executes by interpreting the rule parse tree. At the first triggering, it type checks the parse tree and prepares for reflective e3xecution by hanging a Method instance off every parsed method call (also a Field object off every field access). Type checking is performed with triggering disabled (by a direct call rather than via reflection) so the type check should not cause a recursive entry. However, when the rule engine starts executing that still means your call to setTriggering(false) will need to be executed via a reflective method invocation on method Helper.setTriggering(boolean). Hmm . . .

You might try running with bytecode compilation switched on (set -Dorg.jboss.byteman.compile.to.bytecode on the command line). That ought to avoid the need for reflective execution in the rule engine up to the point where it hits the setTriggering call."