This component (let's call it RulesService) is part of the EAR.
Basically what happens is that it is loaded in a separate class loader,
and those classes load lazily the RuleBaseConfiguration when the first
request hits my webapp which calls this RulesService.
So the CompositeClassLoader has a reference to the webapp class loader
because it happens in the context of the request Thread, and it is
referenced by objects of RulesService which outlive my webapp.
I have decided to intercept the initialization of my webapp, nullify the
context class loader and force the initialization of RulesService and
reset the context class loader.
This is also what Mark just suggested, except that my code is not
responsible of initializing the Drools classes so I had to trick
RulesService into doing it.
This should do it for now.
Thanks,
Romain
From: Davide Sottara <dsotty(a)gmail.com>
To: rules-users(a)lists.jboss.org,
Date: 06/04/2014 02:10
Subject: Re: [rules-users] Memory leak due CompositeClassLoader
Sent by: rules-users-bounces(a)lists.jboss.org
I think I'm starting to see the problem now. Where does this "component"
live
exactly, and how is that (and the KB) shared between your different
webapps?
--
View this message in context:
http://drools.46999.n3.nabble.com/rules-users-Memory-leak-due-CompositeCl...
Sent from the Drools: User forum mailing list archive at
Nabble.com.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users