You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by "Paul Thevenot (JIRA)" <ji...@apache.org> on 2016/10/05 15:31:20 UTC

[jira] [Commented] (ARIES-1603) Aries async classloader leak

    [ https://issues.apache.org/jira/browse/ARIES-1603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15549070#comment-15549070 ] 

Paul Thevenot commented on ARIES-1603:
--------------------------------------

Ok, I've found the issue (sorry, i had to work on other stuff). I found that we were using the jvm parameter noclassgc.. Thus, because the jvm creates classes at runtime, they are not garbage collected and then leak. Sorry, I wasn't aware that we had this parameter and when i found out, i was a bit frustrated..
Anyway, I think the cache you added is still necessary in case the client doesn't keep the mediated objects since it's not mandatory.
You can close this issue I think.

> Aries async classloader leak
> ----------------------------
>
>                 Key: ARIES-1603
>                 URL: https://issues.apache.org/jira/browse/ARIES-1603
>             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
(v6.3.4#6332)