[
https://issues.apache.org/jira/browse/CXF-9091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17925589#comment-17925589
]
Freeman Yue Fang edited comment on CXF-9091 at 2/10/25 2:31 PM:
----------------------------------------------------------------
Hi [~mash-sap],
Thanks for the PR!
More update of this issue. I found the root cause is that on the server side,
firstly in DocLiteralInInterceptor, the message part stream is saved in
MessageContentsList(As StaxSource based on the InputStream in your case), and
later in MAPAggregatorImpl
it calls into
{code}
if (isOneway
|| !ContextUtils.isGenericAddress(maps.getReplyTo())) {
InternalContextUtils.rebaseResponse(maps.getReplyTo(),
maps,
message);
}
{code}
This rebase operation cause thread switch and the InputStream of server side is
closed(hence the StaxSource based on this inputstream is invalid), but later in
Camel-cxf(CachedCxfPayload) this StaxSource is read again, hence we see the
exception
{code}
Current event not START_ELEMENT or END_ELEMENT
{code}
The right fix is to cache the InputStream at some proper point, actually CXF
side has done this when switching thread, but seems too late as
DocLiteralInInterceptor is executed early in the server side interceptor chain.
I am still thinking of a solution to deal with it, but seems your PR
https://github.com/apache/cxf/pull/2262 is promising.
Cheers
Freeman
was (Author: ffang):
Hi [~mash-sap],
Thanks for the PR!
More update of this issue. I found the root cause is that on the server side,
firstly in DocLiteralInInterceptor, the message part stream is saved in
MessageContentsList(As StaxSource based on the InputStream in your case), and
later in MAPAggregatorImpl
it calls into
{code}
if (isOneway
|| !ContextUtils.isGenericAddress(maps.getReplyTo())) {
InternalContextUtils.rebaseResponse(maps.getReplyTo(),
maps,
message);
}
{code}
This rebase operation cause thread switch and the InputStream of server side is
closed(hence the StaxSource based on this inputstream is invalid), but later in
Camel-cxf(CachedCxfPayload) is StaxSource is read again, hence we see the
exception
{code}
Current event not START_ELEMENT or END_ELEMENT
{code}
The right fix is to cache the InputStream at some proper point, actually CXF
side has done this when switching thread, but seems too late as
DocLiteralInInterceptor is executed early in the server side interceptor chain.
I am still thinking of a solution to deal with it, but seems your PR
https://github.com/apache/cxf/pull/2262 is promising.
Cheers
Freeman
> 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)
