Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
Date: Sat, 4 Oct 2014 15:27:33 +0000 (UTC)
From: "Carsten Ziegeler (JIRA)" <jira@apache.org>
To: dev@felix.apache.org
Message-ID: <JIRA.12745697.1412326943000.191137.1412436453631@Atlassian.JIRA>
In-Reply-To: <JIRA.12745697.1412326943000@Atlassian.JIRA>
References: <JIRA.12745697.1412326943000@Atlassian.JIRA>
 <JIRA.12745697.1412326943203@arcas>
Subject: [jira] [Commented] (FELIX-4663) Potential memory leak in
 AsyncDeliveryTask
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Carsten Ziegeler commented on FELIX-4663:
-----------------------------------------

I've added some code in rev 1629402 which should handle the case for the RejectedExecutionException. Not sure though if we should just catch REE or all exceptions (like it is now)

> Potential memory leak in AsyncDeliveryTask
> ------------------------------------------
>
>                 Key: FELIX-4663
>                 URL: https://issues.apache.org/jira/browse/FELIX-4663
>             Project: Felix
>          Issue Type: Bug
>          Components: Event Admin
>    Affects Versions: eventadmin-1.3.2
>            Reporter: Hartmut Lang
>            Assignee: Carsten Ziegeler
>             Fix For: eventadmin-1.4.4
>
>
> EventAdmin 1.3.2 can create an OutOfMemory condition caused by not delivered async events.
> The problem can occur if an interrupted thread issues an async event (e.g. log-event).
> In EventAdmin 1.3.2 the async-delivery uses DefaultThreadPool based on PooledExecutor. 
> If the already interrupted thread enters the execute-method in PooledExecutor an InterruptedException is thrown before the TaskExecutor was added to the Thread-Pool.
> This Exception is catched(not handled, only logged) in the DefaultThreadPool.
> As a result the TaskExecuter was not scheduled in the ThreadPool but is still part of the m_running_threads.
> All new events are added to the pool of the TaskExecuter, adding in a increasing LinkedList. The TaskExecutor is never started again. Memory is leaking.
> Seems that 1.4.x is not vulnerable related to interrupted threads. But the same catch-and-not-handle block is used in 1.4.x. 


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)