Mailing-List: contact dev-help@aries.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@aries.apache.org
Date: Mon, 19 Sep 2016 10:09:20 +0000 (UTC)
From: "Timothy Ward (JIRA)" <jira@apache.org>
To: dev@aries.apache.org
Message-ID: <JIRA.13001308.1472564654000.604011.1474279760633@Atlassian.JIRA>
In-Reply-To: <JIRA.13001308.1472564654000@Atlassian.JIRA>
References: <JIRA.13001308.1472564654000@Atlassian.JIRA> <JIRA.13001308.1472564654643@arcas>
Subject: [jira] [Commented] (ARIES-1603) Aries async classloader leak
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Mon, 19 Sep 2016 10:09:22 -0000


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

Timothy Ward commented on ARIES-1603:
-------------------------------------

The simple answer was that it wasn't - a tidy up before the commit removed the magic line needed. I've fixed that, and added unit tests to prove that the cache is being used, both for interfaces and classes.

> 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)