Thanks for your response. Did open an issue: https://issues.apache.org/jira/browse/FELIX-4663
Hartmut 2014-10-03 10:35 GMT+02:00 Carsten Ziegeler <[email protected]>: > Hi, > > thanks for the great analysis - could you please open a jira issue for > this? > We're not planning any releases for 1.3.x and rather suggest to use the > latest 1.4.x version. The only new requirement of the 1.4 version is Java > 6. > > Carsten > > 2014-10-02 22:21 GMT+02:00 Hartmut Lang <[email protected]>: > > > 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 > > > > > > -- > Carsten Ziegeler > Adobe Research Switzerland > [email protected] >
