[
https://issues.apache.org/jira/browse/CXF-6590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bjørn Hilstad reopened CXF-6590:
--------------------------------
Estimated Complexity: Moderate (was: Unknown)
I verified this fix when it was created and it seemed fine, but it does not
actually handle all cases.
It does not leak memory anymore in the case where the soapfault uses an
wsa.Action of
<wsa:Action>http://www.w3.org/2005/08/addressing/fault</wsa:Action>.
But there is still a leak when the soapfault uses a wsa:Action that can be used
for non WSA related faults. This is
<wsa:Action>http://www.w3.org/2005/08/addressing/soap/fault</wsa:Action> and it
is described in the WS-Addressing specification here:
https://www.w3.org/TR/ws-addr-soap/#faults . The specification says that this
value MAY be used, but you are also allowed to define custom values.
The same reproducer can be used to trigger this but you need to update the
wsa:Action in the response that is sent from the wiremock-part (file
__files\altinnunavailable.xml in archive wiremock.zip)
We have tested againt the latest release of cxf (3.1.7) and the problem is
there to. To change CXF versions in the reproducer you just update the property
cxf.version in pom.xml (archive cxfoom.zip)
> MAPCodec: memory leak with sync client when soapfaults returned from endpoint
> -----------------------------------------------------------------------------
>
> Key: CXF-6590
> URL: https://issues.apache.org/jira/browse/CXF-6590
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
> Affects Versions: 3.0.6
> Environment: CXF 3.0.6, JDK 1.7, CXF 3.1.2
> Reporter: Bjørn Hilstad
> Assignee: Daniel Kulp
> Fix For: 3.1.3, 3.0.7
>
> Attachments: cxfoom.zip, wiremock.zip
>
>
> This bug is similar to CXF-2591 but relates to sync clients.
> A simple client using a service with WS-Addressing which makes repeated calls
> to a service that returns a soapfault will cause a build up of objects in
> MAPCodec::uncorrelatedExchanges.
> The real use case is an application using Apache Camel to keep invoking a
> service that returns a fault (for instance wsa:DestinationUnreachable) using
> the built in redelivery-functions of Apache Camel.
> A simple CXF client that reproduces the issue has been created. The client
> just invokes a service in a loop and by observing the used memory (jconsole)
> and performing memory dumps which can be analyzed using MAT, you can see the
> issue.
> A standalone wiremock functions as the endpoint.
> The reproducers will be attached.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
