Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1002349

Summary: Memory leak in ksession when used Spring Integration + jBPM
Product: [JBoss] JBoss Enterprise BRMS Platform 5 Reporter: Alessandro Lazarotti <alazarot>
Component: jBPM 5Assignee: Kris Verlaenen <kverlaen>
Status: CLOSED UPSTREAM QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: BRMS 5.3.1CC: nwallace
Target Milestone: GA   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2025-02-10 03:28:26 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:
Embargoed:
Bug Depends On:    
Bug Blocks: 1022758    

Description Alessandro Lazarotti 2013-08-29 01:06:46 UTC 
Description of problem:

When a ksession is not disposed between multiple invocations (like by the strategy "one or pull of ksessions per cluster member") together with BRMS Spring integration, the memory usage keep growing after each interaction with the process and some times the exception StaleObjectStateException could occur even without concurrent access to the process.

Process instances in Spring are loaded using the application context, not the command context. This can cause OptimisticLockingExceptions if the process instance was modified elsewhere, as this context is not cleared in between invocations.
Using the command-scoped context will make sure that process instance changes between invocations are picked up at the beginning and don't cause a commit exception at the end.

It is the product 5.3 BZ for the community Jira https://issues.jboss.org/browse/JBPM-3964
Comment 1 Radovan Synek 2014-02-13 17:56:53 UTC 
Verified with BRMS-5.3.1-P05 that:

1. multiple invocations of single ksession does not increase memory usage.
2. using 2 nodes with the reproducer application attached to corresponding support case and following the reproducing steps does not produce any transaction related exceptions.
Comment 3 Red Hat Bugzilla 2025-02-10 03:28:26 UTC 
This product has been discontinued or is no longer tracked in Red Hat Bugzilla.