Hi Andriy,

Just another 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?

Do you have any insights on this async-decoupling, Andriy?

Best regards,
Manuel

-----Original Message-----
From: Shenavai, Manuel <manuel.shena...@sap.com>
Sent: 16 December 2024 09:22
To: Andriy Redko <drr...@gmail.com>; dev@cxf.apache.org
Subject: RE: Camel 3|CXF: ParsingErrors with OneWay Messages

Hi Andriy,

Unfortunately, I don't know how I could switch my example to Camel 2. We used 
to use Camel 2.24. One guess is, that this is not related to Camel/CXF 
directly, but maybe it is related to Tomcat, which (in our case) is changed 
from Tomcat 8 to Tomcat 9.

Best regards,
Manuel

-----Original Message-----
From: Andriy Redko <drr...@gmail.com>
Sent: 15 December 2024 17:47
To: Shenavai, Manuel <manuel.shena...@sap.com>; dev@cxf.apache.org
Subject: Re: Camel 3|CXF: ParsingErrors with OneWay Messages

Hi Manuel,

I briefly looked into the issue and could confirm that there is indeed a 
problem with larger message payload. However,
I could also reproduce it on Camel 2.x (I was using 2.25.4) although the 
exception is slightly different (including it
here for completeness):

Caused by: com.ctc.wstx.exc.WstxEOFException: Unexpected EOF; was expecting a 
close tag for element <data>
at [row,col {unknown-source}]: [22,594]
    at com.ctc.wstx.sr.StreamScanner.throwUnexpectedEOF(StreamScanner.java:687) 
~[woodstox-core-5.0.3.jar:5.0.3]
    at 
com.ctc.wstx.sr.BasicStreamReader.throwUnexpectedEOF(BasicStreamReader.java:5608)
 ~[woodstox-core-5.0.3.jar:5.0.3]
    at 
com.ctc.wstx.sr.BasicStreamReader.nextFromTree(BasicStreamReader.java:2802) 
~[woodstox-core-5.0.3.jar:5.0.3]
    at com.ctc.wstx.sr.BasicStreamReader.next(BasicStreamReader.java:1123) 
~[woodstox-core-5.0.3.jar:5.0.3]
    at 
org.apache.cxf.staxutils.DepthXMLStreamReader.next(DepthXMLStreamReader.java:219)
 ~[cxf-core-3.3.10.jar:3.3.10]
    at 
org.apache.cxf.staxutils.DepthXMLStreamReader.next(DepthXMLStreamReader.java:219)
 ~[cxf-core-3.3.10.jar:3.3.10]
    at 
org.apache.cxf.staxutils.FragmentStreamReader.next(FragmentStreamReader.java:101)
 ~[cxf-core-3.3.10.jar:3.3.10]
    at 
org.apache.camel.component.cxf.converter.DelegatingXMLStreamReader.next(DelegatingXMLStreamReader.java:58)
 ~[camel-cxf-2.25.4.jar:2.25.4]
    at 
java.xml/com.sun.org.apache.xalan.internal.xsltc.trax.StAXStream2SAX.bridge(StAXStream2SAX.java:191)
 ~[na:na]
    at 
java.xml/com.sun.org.apache.xalan.internal.xsltc.trax.StAXStream2SAX.parse(StAXStream2SAX.java:104)
 ~[na:na]
    at 
java.xml/com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transformIdentity(TransformerImpl.java:708)
 ~[na:na]
    at 
java.xml/com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:775)
 ~[na:na]
    ... 42 common frames omitted

Could you please share a branch here [1] for Camel 2.x that works for you?
Thank you.

[1] https://github.com/mash-sap/cxfOneWayError

Best Regards,
     Andriy Redko


> 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.5.2
> Camel CXF: 3.17.0
> Tomcat: 9.0.83

> Anyone else experienced this issue and knows how to fix it?

> Thanks in advance &
> Best regards,
> Manuel

Reply via email to