[jira] [Commented] (FELIX-4663) Potential memory leak in AsyncDeliveryTask

2014-10-05 Thread Hartmut Lang (JIRA)

[ 
https://issues.apache.org/jira/browse/FELIX-4663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

2014-10-04 Thread Carsten Ziegeler (JIRA)

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


[jira] [Commented] (FELIX-4663) Potential memory leak in AsyncDeliveryTask

2014-10-03 Thread Hartmut Lang (JIRA)

[ 
https://issues.apache.org/jira/browse/FELIX-4663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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)


[jira] [Commented] (FELIX-4663) Potential memory leak in AsyncDeliveryTask

2014-10-03 Thread Hartmut Lang (JIRA)

[ 
https://issues.apache.org/jira/browse/FELIX-4663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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)