cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bjørn Hilstad (JIRA) <>
Subject [jira] [Reopened] (CXF-6590) MAPCodec: memory leak with sync client when soapfaults returned from endpoint
Date Thu, 01 Sep 2016 12:37:22 GMT


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></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></wsa:Action>
and it is described in the WS-Addressing specification here:
. The specification says that this value MAY be used, but you are also allowed to define custom

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

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

> MAPCodec: memory leak with sync client when soapfaults returned from endpoint
> -----------------------------------------------------------------------------
>                 Key: CXF-6590
>                 URL:
>             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:,
> 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

View raw message