Bug 1044007

Summary:	KieRepository holds old KieModules forever potentially causing memory problems
Product:	[Retired] JBoss BRMS Platform 6	Reporter:	Mario Fusco <mfusco>
Component:	BRE	Assignee:	Mario Fusco <mfusco>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Marek Winkler <mwinkler>
Severity:	urgent	Docs Contact:
Priority:	urgent
Version:	6.0.0	CC:	etirelli, rzhang
Target Milestone:	ER 7
Target Release:	6.0.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-08-06 20:17:24 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:

Description Mario Fusco 2013-12-17 15:29:22 UTC

KieRepository has an internal data structure where it store the KieModules deployed in it. At the moment those KieModules remain there indefinitely even if they are no longer useful and this could be a potential OutOfMemory cause.

Comment 2 Mario Fusco 2013-12-17 15:30:37 UTC

Fixed by https://github.com/droolsjbpm/drools/commit/43930b285574549fa9d9e8810862bf1306937f36

Comment 3 Edson Tirelli 2013-12-17 15:35:09 UTC

This is a perm gen leak fix, so I asked Mario to immediately cherry-pick into 6.0.x in order to include it in ER7.

Comment 4 JBoss JIRA Server 2013-12-17 16:49:42 UTC

Mario Fusco <mario.fusco> updated the status of jira DROOLS-381 to Reopened

Comment 5 Mario Fusco 2013-12-17 17:25:12 UTC

Unfortunately I found that the solution I implemented (wrapping the KieModules stored by the KieRepository with WeakReferences) doesn't work well as I hoped so I had to rollback it. 

In particular it doesn't play well with CDI and indeed it made to randomly fail org.drools.compiler.cdi.KieBaseInjectionTest. This is because in that case there's no KieContainer immediately referencing a KieModule, but when weld tries to create one the corresponding KieModule could be already garbage collected and then no longer present in the KieRepository.

For the same reason I think that any automatic eviction policy cannot work because we cannot know if it is actually going to evict a KieModule that could be necessary at a later time.

Even if I hoped to avoid that, I think that the only solution to this problem is to add a removeKieModule(ReleaseId) method to the public API of the KieRepository allowing the user to explicitly remove a given KieModule.

Comment 6 Mario Fusco 2013-12-17 18:41:51 UTC

Fixed by https://github.com/droolsjbpm/droolsjbpm-knowledge/commit/342a3b24e0bb66af48f6811d7f4066f00f907d36 and https://github.com/droolsjbpm/drools/commit/88672e348ed9d32c3f74683e91f727c80754350f implementing a method to explicitly remove a no longer used KieModule from the KieRepository

Comment 7 Edson Tirelli 2013-12-18 03:02:14 UTC

Cherry-picked into 6.0.x:

https://github.com/droolsjbpm/droolsjbpm-knowledge/commit/342a3b24e0b
http://github.com/droolsjbpm/drools/commit/d5640b39b

Comment 8 JBoss JIRA Server 2013-12-18 07:28:26 UTC

Mario Fusco <mario.fusco> updated the status of jira DROOLS-381 to Resolved

Comment 9 Marek Winkler 2014-01-07 17:02:25 UTC

Verified that KieRepository.removeKieModule(ReleaseId) works on BRMS 6.0.0 ER7.