Bug 975396

Summary: Drools channels are limited to statefull sessions only
Product: [JBoss] JBoss Fuse Service Works 6 Reporter: Jiri Pechanec <jpechane>
Component: SwitchYardAssignee: Edson Tirelli <etirelli>
Status: CLOSED CURRENTRELEASE QA Contact: Jiri Pechanec <jpechane>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 6.0.0 GACC: atangrin, dward, etirelli, soa-p-jira, tschloss
Target Milestone: ER1   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Jiri Pechanec 2013-06-18 11:24:23 UTC
In DR5

There is a limitation in KnowledgeBaseSessionFactory that channels are registered only if statefull session is used. They are not available for stateless sessions.

I've not found any technical reason why it should not be done for stateless sessions as well as it is natural way how to invoke (one-way) a SY service from Drools rule.

Was not it confused with entry points?

Comment 1 David Ward 2013-06-24 09:37:04 UTC
The technical reason is that the KIE/Drools/jBPM API does not provide a method to register Channels on stateless knowledge sessions - only stateful.  Thus, if your action is type EXECUTE (the default), stateless is used, and Channels can't be registered.  However, if you choose a different action type (FIRE_ALL_RULES, INSERT, FIRE_UNTIL_HALT), then a stateful session is used, and channels will get registered.

Comment 2 Jiri Pechanec 2013-06-24 12:59:12 UTC
According to BRMS team - channels can be used for stateless sessions too.

They are not configured directly via interface calls but via sending commands CommandExecutor.execute(). Internally stateless session is only wrapper around a stateful one.

Thanks to Tomas Schlosser for the information.

Comment 3 David Ward 2013-06-24 13:35:10 UTC
"Internally stateless session is only wrapper around a stateful one."

I know that.  However, every time you issue a Command to a stateless session, a new working memory (and thus new wrapped stateful session) is created.  So I don't think issuing a command to register a Channel, followed by an execute (or a follow-up execute command) is going to work.

The REAL question here is "why did the drools team not expose registration of Channels on stateless sessions"?  If we want to support that in SwitchYard, then I suggest we push for it's direct support from the drools team.

Comment 4 Tomas Schlosser 2013-06-25 07:09:24 UTC
It works using batch execution command:

KieCommands cmdFac = KieServices.Factory.get().getCommands();
List<Command<?>> commands = new LinkedList<Command<?>>();
commands.add(new RegisterChannelCommand("channel-name", new ChannelImplementation()));
// add whatever commands are needed e.g.
//commands.add(cmdFac.newInsert(objectToInsert));
//commands.add(cmdFac.newFireAllRules());
StatelessKieSession session;
session.execute(cmdFac.newBatchExecution(commands, null));

Edson, could you, please, explain why the channels can't be registered on stateless session directly (the way global variables are)?

Comment 5 Edson Tirelli 2013-06-25 13:42:26 UTC
It looks like an API oversight, but I have to check in more detail. We are in the middle of beta4 release. I can try to fix this for CR1. Is that ok? 

Can I assign this ticket to myself, or should we clone it into BRMS?

Comment 6 Edson Tirelli 2013-06-28 20:50:16 UTC
I exposed the channel related methods in the stateless session interface. This will be in the Drools v6.0.0.Beta5 community version. Also available in the master branch for now.

http://github.com/droolsjbpm/droolsjbpm-knowledge/commit/e672d90ea

http://github.com/droolsjbpm/drools/commit/c1bfa6234

Comment 8 David Ward 2013-07-09 17:10:09 UTC
Sorry; I'm new to BZ. Is there documentation for the process somewhere? I was never taught about the "devel_ack" flag.  I thought just associating the JIRA was all I had to do, and what needed to happen after that would happen automagically...

Comment 9 Edson Tirelli 2013-07-09 22:51:06 UTC
Sorry. My mistake. Flag set.

Comment 10 JBoss JIRA Server 2013-08-01 14:22:38 UTC
David Ward <dward> updated the status of jira SWITCHYARD-1576 to Resolved

Comment 11 JBoss JIRA Server 2013-08-01 14:22:38 UTC
David Ward <dward> made a comment on jira SWITCHYARD-1576

Fixed as part of SWITCHYARD-1623.

Comment 12 Jiri Pechanec 2013-09-19 11:23:07 UTC
Verified in ER2

Comment 16 JBoss JIRA Server 2014-06-16 23:53:48 UTC
Keith Babo <kbabo> updated the status of jira SWITCHYARD-1576 to Closed