Bug 780883 (SOA-3340)

Summary: Performance issue in drools integration
Product: [JBoss] JBoss Enterprise SOA Platform 5 Reporter: Kevin Conner <kevin.conner>
Component: JBoss RulesAssignee: Kevin Conner <kevin.conner>
Status: CLOSED NEXTRELEASE QA Contact:
Severity: urgent Docs Contact:
Priority: urgent    
Version: 5.2.0.ER3CC: pmacik
Target Milestone: ---   
Target Release: 5.2.0.ER4   
Hardware: Unspecified   
OS: Unspecified   
URL: http://jira.jboss.org/jira/browse/SOA-3340
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-10-24 12:03:47 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 780812    

Description Kevin Conner 2011-08-31 18:05:13 UTC
project_key: SOA

There is a performance issue in the drools codebase, caused when the drools jbpm jars are not included.

When a stateful or stateless knowledge session is created within drools the drools code base will attempt to create a process runtime and attach it to the session (twice for stateful).  The creation is handled by the ProcessRuntimeFactory class which uses org.jbpm.process.instance.ProcessRuntimeFactoryServiceImpl as the default provider.

We do not support the drools jbpm code within SOA so the associated jars are not present.  The result of this is that every attempt to create a session will result in at least one attempt to load the non-existent class, cause an exception to be thrown and will then return a null for the runtime.

In ESB we can workaround this by checking to see if the provider has been set and, if not, register a default provider.  This can immediately return null rather than go through the classloading/exception route.

Comment 1 Kevin Conner 2011-08-31 18:05:37 UTC
Link: Added: This issue is a dependency of SOA-3258


Comment 2 Kevin Conner 2011-08-31 18:14:38 UTC
Link: Added: This issue depends JBESB-3672


Comment 3 Kevin Conner 2011-08-31 18:18:02 UTC
Workaround has been added into ESB codebase, should be present in ER4

Comment 4 Pavel Macik 2011-10-24 12:03:32 UTC
Verified in 520ER4