[
https://issues.apache.org/jira/browse/CAMEL-18844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rafał Gała updated CAMEL-18844:
-------------------------------
Description:
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:)
was:
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 tne poll method on
ArrayDeque does not do something as expected :)
> 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
> Priority: Critical
> Fix For: 3.21.0, 3.20.1
>
>
> 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)
