[
https://issues.apache.org/jira/browse/CXF-7943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16755904#comment-16755904
]
Sean commented on CXF-7943:
---------------------------
Hi [~coheigea], the issue for us in the end was pretty much what [~dkulp] said,
which was that our relatesTo/messageId value would change in the end – more
specifically our original messageId would have a timestamp at the end of the
value, but later on we removed it -- so that when the uncorrelatedExchanges map
would search for the changed key during delete, the map would find nothing,
thus having the map continue to grow, which makes sense.
> 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
> Fix For: 3.3.1
>
> Attachments: fault_req_resp.xml, histogram.PNG, leak_suspect_1.PNG,
> mapcodec_leak.png, mem_dump.png, ok_req_resp.xml
>
>
> 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)
