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