WAR == single classloader was: Benefits of activeReferenceQueue
David M. Lloyd
david.lloyd at redhat.com
Mon Aug 4 13:42:50 UTC 2014
On 08/04/2014 06:27 AM, Florian Weimer wrote:
> On 08/01/2014 06:39 AM, Jaroslav Tulach wrote:
>> Dne Út 29. července 2014 14:13:25, Florian Weimer napsal(a):
>>> On 07/29/2014 10:05 AM, Jaroslav Tulach wrote:
>>>> Plus, because there is a single classloader which loads all the classes
>>>> from a WAR, by keeping the activerReferenceQueue thread alive and
>>>> reference to the queue, we hold reference to its class and the
>>>> classloader and thus all classes referenced by it.
>>>> And this memory leak accumulates with every re-deploy.
>>> Could you interrupt the thread when URLClassLoader#close() is called?
>> Hello Florian,
>> I am not sure how to hook into URLClassLoader#close? It is the
>> container who
>> creates the classloader, not my library and I don't see any way to add a
>> "listener" to the close method (without a reflection).
> Wouldn't it be the job of the container to provide such notification
> just before unloading the module?
> I wonder if it is possible to fake such notification with finalization
> which is triggered after class unloading, but it seems this needs
> separate class loaders and will likely be rather brittle.
Servlets are EE components, and as such, you should be able to establish
a @PreDestroy interceptor, which was introduced for exactly this kind of
purpose (cleanup and reclaiming of per-component resources). Also
servlets have a destroy method IIRC.
IOW all of this seems unnecessary.
More information about the core-libs-dev