[
https://issues.apache.org/jira/browse/CXF-7943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16750465#comment-16750465
]
Daniel Kulp commented on CXF-7943:
----------------------------------
I've seen this reported before and every time I've investigated it's due to
whatever "load tester" they were using not doing WS-Addressing properly and
sticking bogus values in for the message-ids and RelatesTo headers for
ws-addressing. If the RelatesTo doesn't properly match what the client is
sending, then it cannot be correlated and the messages would not be removed
from the Map. Thus, we would definitely need to see request/response messages.
> MAPCodec: Memory leak due to growing uncorrelatedExchanges
> ----------------------------------------------------------
>
> Key: CXF-7943
> URL: https://issues.apache.org/jira/browse/CXF-7943
> Project: CXF
> Issue Type: Bug
> Affects Versions: 3.2.0
> Environment: CXF 3.2.0, JDK 1.8
> Reporter: Sean
> Priority: Major
> Attachments: histogram.PNG, leak_suspect_1.PNG, mapcodec_leak.png
>
>
> When running load tests, my system begin to get memory leak after 4 hours or
> so. When analyzing the heap dump using VisualVM (please see attachments), I
> can see that a ConcurrentHashMap is taking up 1.7 GB of space in the heap, as
> well as being the main "suspect" for this leak. This leads me to believe that
> it is the uncorrelatedExchanges attribute since this map is being reference
> from the MAPCodec class.
> I believe that the map, in my case, for whatever reason, does not always
> remove the Exchange after the synchronous request/responses are done, however
> I could be wrong.
>
> IF this is indeed a bug, what could the cause of this be, as well as any work
> around?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
