Bug 734367 - Memory leak in stateless session when using CommandFactory.newInsertElements()
Summary: Memory leak in stateless session when using CommandFactory.newInsertElements()
Keywords:
Status: VERIFIED
Alias: None
Product: JBoss Enterprise BRMS Platform 5
Classification: JBoss
Component: BRE (Expert, Fusion)
Version: BRMS 5.2.0.GA
Hardware: x86_64
OS: Linux
unspecified
urgent
Target Milestone: ---
: BRMS 5.2.0.GA
Assignee: Tihomir Surdilovic
QA Contact: Lukáš Petrovický
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-08-30 08:25 UTC by Petr Široký
Modified: 2019-01-01 02:56 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug


Attachments (Terms of Use)
Simple reproducer. (1.75 KB, text/x-java)
2011-08-30 08:25 UTC, Petr Široký
no flags Details


Links
System ID Priority Status Summary Last Updated
JBoss Issue Tracker JBRULES-3217 Critical Resolved Memory leak in stateless session when using CommandFactory.newInsertElements() 2016-01-13 15:59:53 UTC
JBoss Issue Tracker SOA-3341 Blocker Closed Memory leak in stateless session when using CommandFactory.newInsertElements() 2016-01-13 15:59:53 UTC

Description Petr Široký 2011-08-30 08:25:14 UTC
Created attachment 520553 [details]
Simple reproducer.

Description of problem:
There is a memory leak when calling an execute method on StatelessKnowledgeSession with list of Commands(facts). See the reproducer.

According to heap dump, the org.drools.command.runtime.rule.InsertElementsCommand is holding references to facts even after the execute() method is finished. 

This is a regression from 5.1.0 GA.


Version-Release number of selected component (if applicable):
BRMS 5.2.0 ER3

How reproducible:
Always

Steps to Reproduce:
1. Run the attached reproducer with ER3 binaries on classpath.
2. Look at stdout to see the raising heap used memory.
  
Actual results:
Heap used memory is raising.

Expected results:
Heap used memory is not raising. All unused object are collected.

Additional info:
When jBPM jars are not included in classpath, leak is away and memory usage in not raising.

Memory leak does not occur when StatefulKnowledgeSession is used.

Comment 1 Tihomir Surdilovic 2011-09-19 17:22:32 UTC
Mario Fusco has fix this issue and committed also to the 5.2.x branch. Please test.

Comment 2 Petr Široký 2011-09-20 10:41:56 UTC
Verified fixed in 5.2.0 ER4.

Comment 3 lcarlon 2011-09-22 03:40:55 UTC
As this is the first time jbpm will be included with BRMS I have marked this issue as not requiring a release note.

Comment 4 Alessandro Lazarotti 2012-02-09 14:00:24 UTC
A memory leak related to this issue can still happen. To see it you should change in the test attached the ksession.execute(commands) to ksession.execute(CommandFactory.newBatchExecution(commands))

I created a new pull request about it: https://github.com/droolsjbpm/drools/pull/94

If it's ok, please merge it on branch 5.3.x and upstream.

Comment 5 JBoss JIRA Server 2012-02-13 14:18:50 UTC
Alessandro Lazarotti <alazarot@redhat.com> updated the status of jira JBRULES-3217 to Reopened

Comment 6 JBoss JIRA Server 2012-02-13 14:18:50 UTC
Alessandro Lazarotti <alazarot@redhat.com> made a comment on jira JBRULES-3217

A memory leak related to this issue can still happen. To see it you should
change in the test attached the ksession.execute(commands) to
ksession.execute(CommandFactory.newBatchExecution(commands))

I created a new pull request about it:
https://github.com/droolsjbpm/drools/pull/94

If it's ok, please merge it on branch 5.3.x and upstream.

Comment 7 JBoss JIRA Server 2012-02-13 14:19:54 UTC
Alessandro Lazarotti <alazarot@redhat.com> made a comment on jira JBRULES-3217

The test is attached at https://bugzilla.redhat.com/show_bug.cgi?id=734367

Comment 8 JBoss JIRA Server 2012-02-13 18:11:32 UTC
Mario Fusco <mario.fusco@gmail.com> updated the status of jira JBRULES-3217 to Resolved

Comment 9 JBoss JIRA Server 2012-02-13 18:11:32 UTC
Mario Fusco <mario.fusco@gmail.com> made a comment on jira JBRULES-3217

The current fix is enough and no other memory leaks can actually be reproduced on both 5.3.x and master.


Note You need to log in before you can comment on or make changes to this bug.