Bug 780362 (SOA-2771)

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(),
                                                              this.ruleBase,
                                                              (SessionConfiguration) this.conf,
                                                              this.environment );

            // 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

Attachment: Added: drools-core-5.1.0.BRMS.jar

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.