Rafał Gała created CAMEL-18844:
----------------------------------

             Summary: 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


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

 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to