[rules-users] Memory leak due CompositeClassLoader

[Romain Thouvenin]

Before asking for an upgrade to this third party, I did a test.
I managed to assemble a build of the component using Drools 5.6.0.Final, 
and tried to use-and-redeploy my webapp.

I did not face any problem due to the upgrade, but it seems the leak is 
still there.
Out of the two instances of CompositeClassLoader that I could see with 
5.2.1, one has gone so it is going in the good direction.
But there is still one that prevents garbage collection.

The CompositeClassLoader is given the webapp class loader instance when it 
is instantiated by RuleBaseConfiguration:

   ClassLoaderUtil.getClassLoader(ClassLoader[], Class<?>, boolean) line: 
43 
   at RuleBaseConfiguration.setClassLoader(ClassLoader...) line: 945 
   at RuleBaseConfiguration.init(Properties, ClassLoader...) line: 421 
   at RuleBaseConfiguration.<init>() line: 267 
   at RuleBaseConfiguration.<clinit>() line: 175 


Any work-around available in 5.6?

Thanks,
Romain





From:   Mark Proctor <mproctor at codehaus.org>
To:     Rules Users List <rules-users at lists.jboss.org>, 
Date:   01/04/2014 19:38
Subject:        Re: [rules-users] Memory leak due CompositeClassLoader
Sent by:        rules-users-bounces at lists.jboss.org



There were a lot of fixes around this and other areas. Please upgrade to 
5.6, then come back if you have problems.

Mark
On 1 Apr 2014, at 14:24, Romain Thouvenin <romain.thouvenin at amadeus.com> 
wrote:

Hello, 

I am working on a Web application that uses a third-party component that 
uses Drools 5.2.1 (I know this is old, but this is not my choice). 
While investigating memory leaks in my application, I found out that after 
redeploying the webapp in the application server (Weblogic), the leaking 
class loader is referenced by: 

   org.drools.util.CompositeClassLoader.classLoaders 

This is because when that class is instantiated by 
org.drools.util.ClassLoaderUtil, the initial list of class loaders 
includes the context class loader of the current thread, which is the 
class loader of my webapp. But the class loader of CompositeClassLoader is 
not the same as my webapp, so when I redeploy my webapp 
CompositeClassLoader continues to exist and keep that reference to the 
webapp class loader, which is therefore never garbage-collected. 

Browsing a bit through the code, I see no reference to 
CompositeClassLoader.removeClassLoader that could remove the faulty 
reference. 

So my questions are: 
1) Is my investigation correct? 

2) I found this thread on the list: 
http://drools.46999.n3.nabble.com/permgen-leak-td4027038i20.html 
Is this the same issue as mine, meaning that it is fixed in 5.6.0 and 6.0? 

If yes, pushing this third-party component to upgrade is really the only 
solution I have? 

I am not at all a knowledgeable user of drools, I just happen to be user 
of that third-party component, that is why I wanted confirmation of my 
findings. 

Thanks for your help! 
Romain 

_______________________________________________
rules-users mailing list
rules-users at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20140402/9451904c/attachment-0001.html