[jira] [Commented] (FELIX-4663) Potential memory leak in AsyncDeliveryTask
[ https://issues.apache.org/jira/browse/FELIX-4663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14159486#comment-14159486 ] Hartmut Lang commented on FELIX-4663: - That is exactly how i would have solved this issue. I think i would change it to only catch the REE. Because here we do not see the exceptions of the actual thread execution, but only the exceptions that can occur in scheduling the task on the thread-pool, right? So basically REE is the only exception that can occur at all. Thx for your quick fix! 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)
[jira] [Commented] (FELIX-4663) Potential memory leak in AsyncDeliveryTask
[ https://issues.apache.org/jira/browse/FELIX-4663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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)
[jira] [Commented] (FELIX-4663) Potential memory leak in AsyncDeliveryTask
[
https://issues.apache.org/jira/browse/FELIX-4663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14157815#comment-14157815
]
Hartmut Lang commented on FELIX-4663:
-
The critical code parts in 1.3.2 are:
{code:title=AsyncDeliverTask.java}
final Thread currentThread = Thread.currentThread();
TaskExecuter executer = null;
synchronized (m_running_threads )
{
final TaskExecuter runningExecutor =
(TaskExecuter)m_running_threads.get(currentThread);
if ( runningExecutor != null )
{
runningExecutor.add(tasks, event);
}
else
{
executer = new TaskExecuter( tasks, event, currentThread );
m_running_threads.put(currentThread, executer);
}
}
if ( executer != null )
{
m_pool.executeTask(executer);
}
{code}
and
{code:title=DefaultThreadPool.java}
public void executeTask(final Runnable task)
{
try
{
super.execute(task);
}
catch (final Throwable t)
{
LogWrapper.getLogger().log(
LogWrapper.LOG_WARNING,
Exception: + t, t);
// ignore this
}
}
{code}
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
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)
[jira] [Commented] (FELIX-4663) Potential memory leak in AsyncDeliveryTask
[ https://issues.apache.org/jira/browse/FELIX-4663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14157817#comment-14157817 ] Hartmut Lang commented on FELIX-4663: - Please also check if 1.4.2 can cause the same situation if ExecutorService of the DefaultThreadPool throws an RejectedExecutionException. 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 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)
