aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Timothy Ward (JIRA)" <>
Subject [jira] [Commented] (ARIES-1603) Aries async classloader leak
Date Tue, 13 Sep 2016 19:04:22 GMT


Timothy Ward commented on ARIES-1603:

bq. What is the purpose of the classloader clone? The prevent an execution after a service

The class loader clone exists for a few reasons:
* For consistency with the class type mediation that requires a class loader clone for CGLib
* To avoid future issues if/when additional types need to be referenced by the proxy
* To avoid lifecycle issues if the async service is uninstalled - using the raw bundle's class
loader would leave proxy types defined on it after the Async bundle was removed from the system.

Technically the way in which the code is written is not leaking class loaders. A different
class loader is used for each mediation, but these will all be eligible for garbage collection
as soon as the mediator is garbage collected. Mediators are intended to be cached and reused
but if the application code makes a lot of them and holds onto them then that will cause a
lot of ClassLoaders to be created. In your application's case I'm not sure where the mediators
end up being held, but that's the reason that an OOM occurs. This may indicate a leak in the
application, or just a high load of concurrent tasks that should be throttled more carefully.

Obviously the application code needs some attention, but having looked more deeply at this
the Async service *may* be able to weakly cache the class loader to be used for mediation.
This should dramatically reduce the memory overhead for your application (although it won't
fix a leak in it if there is one) and help with the scaling.

> Aries async classloader leak
> ----------------------------
>                 Key: ARIES-1603
>                 URL:
>             Project: Aries
>          Issue Type: Bug
>    Affects Versions: async-1.0.2
>            Reporter: Paul Thevenot
> Using the async service with repeated tasks during one hour leads to an out of memory.
It's due to the very large amount of class loaded (in 10 min we get 20000 classes loaded).
The metaspace is growing indefinitely.
> It seems to come from the privMediate method of the AsyncService where the classloader
of the target service is cloned.

This message was sent by Atlassian JIRA

View raw message