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
