Red Hat Bugzilla – Bug 780362
Ruleflow broken inside BusinessRulesProcessor
Last modified: 2011-02-17 03:47:35 EST
The following ruleflow (see attachment) doesn't execute properly inside BusinessRulesProcessor action. There are no exceptions in the log, just the following:
2011-01-14 10:13:15,400 DEBUG [org.jboss.soa.esb.lifecycle.LifecycleResource] (pool-46-thread-1) Creating resource using factory: org.jboss.internal.soa.esb.services.rules.DroolsRuleService$LifecycleRuleBaseStateFactory@41be1cac with identity ID-14
2011-01-14 10:13:15,413 DEBUG [org.jboss.internal.soa.esb.services.rules.DroolsRuleBaseState] (pool-46-thread-1) created new stateless session 
2011-01-14 10:13:15,413 DEBUG [org.jboss.internal.soa.esb.services.rules.DroolsRuleBaseState] (pool-46-thread-1) created new runtime logger 
2011-01-14 10:13:15,413 DEBUG [org.jboss.internal.soa.esb.services.rules.DroolsRuleBaseState] (pool-46-thread-1) calling execute(Iterable) on stateless session 
2011-01-14 10:13:15,434 INFO [STDOUT] (pool-46-thread-1) startRuleFlow
2011-01-14 10:13:15,435 INFO [STDOUT] (pool-46-thread-1) rfg1a
2011-01-14 10:13:15,437 INFO [STDOUT] (pool-46-thread-1) rfg1b
2011-01-14 10:13:15,437 DEBUG [org.jboss.internal.soa.esb.services.rules.DroolsRuleBaseState] (pool-46-thread-1) calling close() on runtime logger 
2011-01-14 10:13:15,509 DEBUG [org.jboss.soa.esb.listeners.message.ActionProcessingPipeline] (pool-46-thread-1) executing processor 1 org.jboss.soa.esb.samples.quickstart.businessrules5jbqa1855.ReviewMessage@9e69443
See that after the activation of rfg1b, the ruleflow simply exits while it should do a lot more stuff, mainly activate rfg2a and rfg4. When launched from Guvnor deployed into the very same SOA instance, it works fine.
1) A RuleFlow and a subflow that is supposed to be called.
2) The DRL file containing all the ruleflow groups and their rules.
3) Audit log from the Drools execution, showing that it simply ends after rfg1b.
4) The ESB archive with the quickstart. Mmay need some tweaking - mainly to update the path to the audit log in jboss-esb.xml and to update agent.pkg.properties to point to the Drools package. (Also packaged inside the archive.)
Attaching the above mentioned files. If necessary, I can also attach the Guvnor repository that can be used to generate the defaultPackage.pkg on-the-fly.
Attachment: Added: Quickstart_business_rules_service5_jbqa-1855.esb
Attachment: Added: LATEST.drl
Attachment: Added: defaultPackage.pkg
Attachment: Added: ruleflowIntg.rf
Attachment: Added: subruleflowIntg.rf
Attachment: Added: business_rules_service5_jbqa-1855.log
Can you attach the full quickstart to this issue so that I can run it?
Attaching a version of the quickstart that should be easily runnable the usual way (ant deploy/runtest inside /samples/quickstarts).
When the functionality works, everything should proceed cleanly. With this bug however, ReviewMessage will throw an exception "Expectations are not met", telling the user that not every rule from the ruleflow has been fired.
Attachment: Added: business_rules_service5_qe.tar.bz2
Repository to import into BRMS to allow for testing the ruleflow.
Attachment: Added: repository_export.zip
The difference between the BRMS and ESB quickstart executions is that BRMS is running this as a stateful session and this quickstart is executing as a stateless.
I believe that this should work with a stateless session but that there may be a bug in the StatelessKnowledgeSessionImpl class.
The execution fails because the event handler responsible for signalling the continuation of the process has been lost, a consequence of code within the StatelessKnowledgeSessionImpl.
Creation of the working memory (1) results in the initialisation of process listeners, including one triggered by the afterRuleFlowGroupDeactivated event. Unfortunately newWorkingMemory() then replaces these listeners with those of the session (2).
1 ==> ReteooWorkingMemory wm = new ReteooWorkingMemory( this.ruleBase.nextWorkingMemoryCounter(),
// we don't pass the mapped listener wrappers to the session constructor anymore,
// because they would be ignored anyway, since the wm already contains those listeners
StatefulKnowledgeSessionImpl ksession = new StatefulKnowledgeSessionImpl( wm,
new KnowledgeBaseImpl( this.ruleBase ) );
((Globals) wm.getGlobalResolver()).setDelegate( this.sessionGlobals );
wm.setKnowledgeRuntime( ksession );
wm.setWorkingMemoryEventSupport( this.workingMemoryEventSupport );
wm.setAgendaEventSupport( this.agendaEventSupport );
2 ==> wm.setRuleFlowEventSupport( this.ruleFlowEventSupport );
branch for fix: https://svn.jboss.org/repos/labs/labs/jbossrules/soa_branches/BRMS-5.1-GA_SOA-2771/
fix committed to above branch. please retest (assigning back to Lukáš)
Will have to wait for another SOA build.
I'll take this until we get it into a SOA build
Attached is the drools-core jar you can test with for now without having to build the branch.
Attachment: Added: drools-core-5.1.0.BRMS.jar
Link: Added: This issue depends BRMS-542
Link: Added: This issue depends SOA-2841
added cleanup method to stateless session for ruleflow event listeners. new drools-core jar here
Assigning back to Lukas for testing. You can build the branch or just use the attached drools-core-5.1.0.BRMS.jar (make sure to use the one from today).
I verified with the latest bits that it is indeed fixed. Reassigning to Kevin to handle resolving the issue.
included in drools pickup
Verified fixed in CR1.
Writer: Added: Darrin
Release Notes Docs Status: Added: Documented as Resolved Issue
Release Notes Text: Added: RuleFlow would sometimes not execute correctly inside of the BusinessRulesProcessor ESB action. This was because it was running in a stateless session instead of a stateful session as would be normally be expected. The stateless session handling code has been updated to handle this type of scenario better.