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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users