[
https://issues.apache.org/jira/browse/CXF-9091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17925598#comment-17925598
]
Manuel Shenavai commented on CXF-9091:
--------------------------------------
Hi [~ffang], the interesting part is, that the rebase operation is already
caching the request payload:
https://github.com/apache/cxf/blob/3.6.x-fixes/rt/ws/addr/src/main/java/org/apache/cxf/ws/addressing/impl/InternalContextUtils.java#L276
But due to missing property (cxf.io.cacheinput) the inputStream is
read/consumed here:
https://github.com/apache/cxf/blob/3.6.x-fixes/rt/transports/http/src/main/java/org/apache/cxf/transport/http/AbstractHTTPDestination.java#L605
https://github.com/apache/cxf/blob/3.6.x-fixes/rt/transports/http/src/main/java/org/apache/cxf/transport/http/AbstractHTTPDestination.java#L626
When eventually the workerThread tries to read the payload, the inputStreams
position is already at the end which leads to the parser error. So the initial
idea was to reset() the inputstream, which worked.
But I guess that using the property (cxf.io.cacheinput) is the correct way to
let cxf know that this is a cached payload.
Best regards,
Manuel
> 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
> Assignee: Freeman Yue Fang
> Priority: Major
> Attachments: GenericRequestReply_wsdl_myendpoint.wsdl
>
>
> 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)
