[
https://issues.apache.org/jira/browse/CXF-9091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17906642#comment-17906642
]
Manuel Shenavai edited comment on CXF-9091 at 12/18/24 8:10 AM:
----------------------------------------------------------------
One noteable observation:
Sending an incomplete payload which is expected to be not parseable, a HTTP 202
returned in the new codeline. While on the old codeline this same request
failed already in the HTTP thread, which led to HTTP 500 instead of HTTP 202.
In our old codeline, this is the stacktrace for a wrong XML. Client receives
HTTP 500
Daemon Thread [https-jsse-nio-8041-exec-18]
org.apache.cxf.binding.soap.saaj.SAAJInInterceptor.handleMessage(SAAJInInterceptor.java:262)
org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.getSOAPMessage(WSS4JInInterceptor.java:167)
org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessageInternal(WSS4JInInterceptor.java:234)
org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:200)
org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JInInterceptor.handleMessage(PolicyBasedWSS4JInInterceptor.java:80)
org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JInInterceptor.handleMessage(PolicyBasedWSS4JInInterceptor.java:67)
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:267)
org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:234)...
The new codeline gets a HTTP 202.
was (Author: mash-sap):
One noteable observation:
Sending an incomplete payload which is expected to be not parseable, a HTTP 202
returned in the new codeline. While on the old codeline this same request
failed already in the HTTP thread, which led to HTTP 500 instead of HTTP 202.
In our old codeline, this is the stacktrace for a wrong XML. Client receives
HTTP 500
Daemon Thread [https-jsse-nio-8041-exec-18]
org.apache.cxf.binding.soap.saaj.SAAJInInterceptor.handleMessage(SAAJInInterceptor.java:262)
org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.getSOAPMessage(WSS4JInInterceptor.java:167)
org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessageInternal(WSS4JInInterceptor.java:234)
org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:200)
org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JInInterceptor.handleMessage(PolicyBasedWSS4JInInterceptor.java:80)
org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JInInterceptor.handleMessage(PolicyBasedWSS4JInInterceptor.java:67)
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:267)
org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:234)...
The new codeline gets a HTTP 202.
Can this be the root cause, that the incoming payload is not read before
returning HTTP 202, hence the input stream is later not available anymore?
> Camel 3|CXF: ParsingErrors with OneWay Messages
> -----------------------------------------------
>
> Key: CXF-9091
> URL: https://issues.apache.org/jira/browse/CXF-9091
> Project: CXF
> Issue Type: Bug
> Reporter: Manuel Shenavai
> Priority: Major
>
> Hi everyone,
> we recently moved from Camel 2 to Camel 3 and we are now observing the
> following problem with CXF. If a OneWay message exceeds a certain length, the
> messages fail with a parser error like:
> Caused by: java.lang.IllegalStateException: Current event not START_ELEMENT
> or END_ELEMENT
> at
> com.ctc.wstx.sr.BasicStreamReader.getNamespaceCount(BasicStreamReader.java:805)
> ~[woodstox-core-6.2.7.jar:6.2.7]
> at
> org.apache.cxf.staxutils.DepthXMLStreamReader.getNamespaceCount(DepthXMLStreamReader.java:122)
> ~[cxf-core-3.5.2.jar:3.5.2]
> at
> org.apache.cxf.staxutils.DepthXMLStreamReader.getNamespaceCount(DepthXMLStreamReader.java:122)
> ~[cxf-core-3.5.2.jar:3.5.2]
> at
> org.apache.camel.component.cxf.converter.DelegatingXMLStreamReader.<init>(DelegatingXMLStreamReader.java:40)
> ~[camel-cxf-3.17.0.jar:3.17.0]
> at
> org.apache.camel.component.cxf.converter.CxfPayloadConverter.convertTo(CxfPayloadConverter.java:225)
> ~[camel-cxf-3.17.0.jar:3.17.0]
> at
> org.apache.camel.component.cxf.converter.CxfPayloadConverterLoader.lambda$registerFallbackConverters$8(CxfPayloadConverterLoader.java:68)
> ~[camel-cxf-3.17.0.jar:3.17.0]
> at
> org.apache.camel.support.SimpleTypeConverter.convertTo(SimpleTypeConverter.java:101)
> ~[camel-support-3.17.0.jar:3.17.0]
> ... 30 common frames omitted
> The error will not happen if we reduce the length of the message or if we
> change it from OneWay to ResponseReply. This indicates a problem in the async
> decoupling of the request.
> During debugging I found that the HTTP thread is used to handle the request.
> But the actual processing of the message happens in new thread. Maybe the
> input stream is closed after the http thread is finished (HTTP 202) and the
> spawned thread cannot read the full content anymore.
> I created the following reproducer based on Spring Boot:
> [https://github.com/mash-sap/cxfOneWayError/tree/main]
> CXF: 3.6.5
> Camel CXF: 3.17.0
> Tomcat: 9.0.83
> Mailinglist Post:
> https://lists.apache.org/thread/vproojr7pcygpjtrygfxj8qcgj1x2q4x
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
