cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrei Shakirin (JIRA)" <>
Subject [jira] [Commented] (CXF-2795) Memory leaks in case of incorrect SOAP/JMS response
Date Thu, 27 Dec 2012 18:12:12 GMT


Andrei Shakirin commented on CXF-2795:


Tried to reproduce this issue on CXF 2.7.1 using spring JMS configuration.
Scenario: CXF client sends messages to the queue in loop, JMS client receives these messages
and replies with a text (non XML) into ReplyTo queue.

CXF client throws expected exception:
Caused by: com.ctc.wstx.exc.WstxUnexpectedCharException: Unexpected character 'H' (code 72)
in prolog; expected '<'
 at [row,col {unknown-source}]: [1,1]
	at org.apache.cxf.binding.soap.interceptor.ReadHeadersInterceptor.handleMessage(
	... 18 more

Memory usage looks correctly for me, I cannot detect memory leaks neither with JProfiler no
with JConsole.
Corresponded images are attached.

I would propose to retest the issue with the latest CXF version and if the problem will not
be detected anymore - close it.

> Memory leaks in case of incorrect SOAP/JMS response
> ---------------------------------------------------
>                 Key: CXF-2795
>                 URL:
>             Project: CXF
>          Issue Type: Bug
>          Components: Configuration, Soap Binding, Transports
>    Affects Versions: 2.2.7
>         Environment: Windows XP, Solaris, 
> Tibco EMS v.4.4.3, 
> JProfiler 6.0.3
>            Reporter: Konstantin Ushakov
>              Labels: conduit, jms, memory_leak, soap
>         Attachments: memory-usage-for-jms-error-1.png, memory-usage-for-jms-error-2.png
> 1. Generate CXF client (Conduit) from WSDL
> 2. Transport = JMS
> 3. receiveTimeout set to some value
> 4. Send request to some backend (e.g. Mock)
> 5. Get correct (according WSDL) response .  
> 6. Observe objects in memory, related to message caching (com.sun.xml.messaging.saaj.soap.ver1_1.Message1_1Impl
and related ones). In appropriate time they disappear. OK.
> 7. Send request
> 8. Get exception response according WSDL schema, or other responce according schema that
leads to exception (e.g. wrong WS policy)
> 9. Observe same objects in memory. In appropriate time they disappear. OK.
> 10. Send request
> 11. Put to the output queue response to request NOT according WSDL schema, e.g. just
text string. This case imitates e.g. wrong backend functionality.
> 12. Observe same objects in memory. 
>           The mentioned objects are kept in memory    FOREVER
> So, it means that the memory leaks exist. In case of big requested the OutOfMemory error

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message