[
https://issues.apache.org/jira/browse/CAMEL-18844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17652442#comment-17652442
]
Rafał Gała commented on CAMEL-18844:
------------------------------------
Thank you. I tested with the provided JAR. The good news is that it does not
leak anymore, the bad news is that performance has degraded :( Threads are
mostly waiting for obtaining locks:
{noformat}
"Camel (camel-1) thread #356 - jt400://***MASKED**** - Thread t@547
java.lang.Thread.State: WAITING
at jdk.internal.misc.Unsafe.park(Native Method)
- parking to wait for <364e961d> (a
java.util.concurrent.locks.ReentrantLock$FairSync)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:885)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:917)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1240)
at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:267)
at
java.util.concurrent.ArrayBlockingQueue.offer(ArrayBlockingQueue.java:341)
at
org.apache.camel.impl.console.EventConsole$ConsoleEventNotifier.notify(EventConsole.java:174)
at
org.apache.camel.support.EventHelper.doNotifyEvent(EventHelper.java:1514)
at
org.apache.camel.support.EventHelper.notifyExchangeAsyncProcessingStartedEvent(EventHelper.java:1502)
at
org.apache.camel.processor.SendProcessor.process(SendProcessor.java:174)
at
org.apache.camel.processor.errorhandler.RedeliveryErrorHandler$RedeliveryTask.doRun(RedeliveryErrorHandler.java:818)
at
org.apache.camel.processor.errorhandler.RedeliveryErrorHandler$RedeliveryTask.run(RedeliveryErrorHandler.java:726)
at
org.apache.camel.impl.engine.DefaultReactiveExecutor$Worker.schedule(DefaultReactiveExecutor.java:181)
at
org.apache.camel.impl.engine.DefaultReactiveExecutor.scheduleMain(DefaultReactiveExecutor.java:59)
at org.apache.camel.processor.Pipeline.process(Pipeline.java:165)
at
org.apache.camel.impl.engine.CamelInternalProcessor.process(CamelInternalProcessor.java:392)
at
org.apache.camel.impl.engine.DefaultAsyncProcessorAwaitManager.process(DefaultAsyncProcessorAwaitManager.java:83)
at
org.apache.camel.support.AsyncProcessorSupport.process(AsyncProcessorSupport.java:41)
at
org.apache.camel.component.jt400.Jt400DataQueueConsumer.poll(Jt400DataQueueConsumer.java:60)
at
org.apache.camel.support.ScheduledPollConsumer.doRun(ScheduledPollConsumer.java:202)
at
org.apache.camel.support.ScheduledPollConsumer.run(ScheduledPollConsumer.java:116)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.lang.Thread.run(Thread.java:834){noformat}
> Possible memory leak in org.apache.camel.impl.console.EventConsole
> ------------------------------------------------------------------
>
> Key: CAMEL-18844
> URL: https://issues.apache.org/jira/browse/CAMEL-18844
> Project: Camel
> Issue Type: Bug
> Components: camel-core
> Affects Versions: 3.20.0
> Reporter: Rafał Gała
> Assignee: Claus Ibsen
> Priority: Critical
> Fix For: 3.21.0, 3.20.1
>
> Attachments: camel-console-3.20.1-SNAPSHOT.jar
>
>
> Today I have upgraded from 3.18.4 to 3.20.0 and did tests under heavy load as
> usual. After processing of approximately 3 millions of exchanges JVM's heap
> usage reached 4GB and it ran out of memory. I analyzed a dump in Eclipse MAT
> and it showed the following:
> {noformat}
> One instance of org.apache.camel.spring.boot.SpringBootCamelContext loaded by
> org.apache.catalina.loader.ParallelWebappClassLoader @ 0x700b5adb0 occupies 3
> 276 629 016 (97,38%) bytes. The memory is accumulated in one instance of
> java.lang.Object[], loaded by <system class loader>, which occupies 3 276 529
> 992 (97,38%)
> bytes.Keywordsorg.apache.camel.spring.boot.SpringBootCamelContextorg.apache.catalina.loader.ParallelWebappClassLoader
> @ 0x700b5adb0java.lang.Object[]{noformat}
> I discovered that the *java.util.ArrayDeque* instance in
> *org.apache.camel.impl.console.EventConsole* instance (most probably the
> exchangeEvents one) contains references to over 12 millions of various
> org.apache.camel.impl.event.* objects, like {*}ExchangeCreatedEvent{*},
> *ExchangeSentEvent* etc.
> I will investigate this further, but it looks like the poll method on
> ArrayDeque does not do something as expected or is used in a wrong way:)
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
