Se the currentContext ClassLoader to null, when initialising the knowledge
base. Then reset it after you are done.
Mark
On 2 Apr 2014, at 08:04, Romain Thouvenin romain.thouve...@amadeus.com wrote:
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 mproc...@codehaus.org
To:Rules Users List rules-users@lists.jboss.org,
Date:01/04/2014 19:38
Subject:Re: [rules-users] Memory leak due CompositeClassLoader
Sent by:rules-users-boun...@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.thouve...@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
