[
https://issues.apache.org/jira/browse/CXF-2795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13540082#comment-13540082
]
Andrei Shakirin commented on CXF-2795:
--------------------------------------
Hi,
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
com.ctc.wstx.sr.StreamScanner.throwUnexpectedChar(StreamScanner.java:639)
at
com.ctc.wstx.sr.BasicStreamReader.nextFromProlog(BasicStreamReader.java:2029)
at com.ctc.wstx.sr.BasicStreamReader.next(BasicStreamReader.java:1114)
at
com.ctc.wstx.sr.BasicStreamReader.nextTag(BasicStreamReader.java:1137)
at
org.apache.cxf.binding.soap.interceptor.ReadHeadersInterceptor.handleMessage(ReadHeadersInterceptor.java:139)
... 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.
Cheers,
Andrei.
> Memory leaks in case of incorrect SOAP/JMS response
> ---------------------------------------------------
>
> Key: CXF-2795
> URL: https://issues.apache.org/jira/browse/CXF-2795
> 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 appears.
--
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: http://www.atlassian.com/software/jira
