[
https://issues.apache.org/jira/browse/CAMEL-7635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14074161#comment-14074161
]
Claus Ibsen commented on CAMEL-7635:
------------------------------------
The issue seems to be that request/reply over JMS having replies not coming
back within the timeout period, so a timeout is triggered, and being processed.
But a NPE is being thrown somewhere during the onTimeout, which causes the
timeout entry to not be removed, and reprocessed the next time the timeout
eviction process is being run (by default every 1 sec). So this can also be
seen from the headdump that the entries are 1 second apart.
CAMEL-7636 should fix the issue so the entry is being removed in cause of an
exception. But the NPE may be triggered in some end user code or something, so
best to track that down.
> Memory leak in Message History feature
> --------------------------------------
>
> Key: CAMEL-7635
> URL: https://issues.apache.org/jira/browse/CAMEL-7635
> Project: Camel
> Issue Type: Bug
> Components: camel-core
> Affects Versions: 2.13.1
> Environment: Apache ServiceMix 5.1.0 w/ Camel 2.13.1
> JDK 7
> Reporter: Raúl Kripalani
> Assignee: Claus Ibsen
> Attachments: Screen Shot 2014-07-24 at 15.32.05.png, image1.png,
> image2.png, image3.png
>
>
> We just had an OOM incident in our dev environments after upgrading from
> Camel 2.10.3 to 2.13.1. Heap settings have remained untouched.
> A heap dump showed millions of DefaultMessageHistory instances retained (see
> [^image1.png]), along with their corresponding Date and StopWatch instances.
> Obviously our first solution will be to disable message history in all
> contexts.
> Digging deeper, I'm utterly confused because I don't seem to find the GC
> roots that are keeping these objects alive.
> OQL query for VisualVM:
> {code}
> select x from org.apache.camel.impl.DefaultMessageHistory x where
> count(referrers(x)) > 0
> {code}
> returns many objects, which is good.
> However, they are referenced by some Object[] which in turn has no referrers
> (!), see [^image2.png].
> Using the "Find nearest GC root" feature yields no results either.
> This mysterious Object[] seems to be filled from position 4072 onwards (see
> [^image3.png]), it has 9k+ items... Perhaps some kind of Queue? There are
> many more Object[] arrays storing DefaultMessageHistory instances too.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
