Hi all, using EventAdmin 1.3.2 we run in an OutOfMemory issue caused be not delivered async events. Drilling down the problem i found that the problem is caused by an interrupted thread which issues an 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 a 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.
As stated we see this in EventAdmin 1.3.2. I understand that EventAdmin 1.4.x was changed using ExecutorService instead of PooledExecutor. Also e.g. FELIX-4627 <https://issues.apache.org/jira/browse/FELIX-4627> seems to fix a leaking problem in 1.4.2 But still i see the not handled (only logging) exception catched in DefaultThreadPool. public void executeTask(final Runnable task) { try { this.executor.submit(task); } catch (final Throwable t) { LogWrapper.getLogger().log( LogWrapper.LOG_WARNING, "Exception: " + t, t); // ignore this } } The submit-call here does not throw InterruptedException so a already interrupted task entring this section can not cause harm, right? But the submit method can potentially throw a RejectedExecutionException. Couldn't this also result in the same condition? TaskExecutor not scheduled but still added to m_running_threads? Is there a bug-fix planned for 1.3.x? Or do we have to switch to 1.4.x? Thanks for reading this long message ;-) Hartmut
