[
https://issues.apache.org/jira/browse/CXF-9135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18132642#comment-18132642
]
Valentino Porta edited comment on CXF-9135 at 10/27/26, 5:23 PM:
-----------------------------------------------------------------
Hi [~ffang] ,
sorry to reopen this discussion.
I also came across the same race condition that [~vbeilin] described.
Experimenting on my local pc I noticed that using a Spring-Camel-Cxf BOM ...
with a local wiremock as a backend ... the first call ran smoothly ... but from
the second and beyond it always ends up with the error "SocketTube(1)
[HttpClient-1-Worker-0] Too few bytes returned by the publisher (0/206)".
Based on the indication [~vbeilin] gave above, I debug the service and also
found that there where a race condition in the
[HttpClientWrappedOutputStream.close()|https://github.com/apache/cxf/blob/main/rt/transports/http/src/main/java/org/apache/cxf/transport/http/HttpClientHTTPConduit.java#L823]
(http-nio thread ) that set to null a OutputStream pout; before the
HttpClientSizedBodyPublisher.subscribe (httpClient thread) could use it.
Here my Camel reproducer:
[https://github.com/vp340/cxf-log-example/tree/CXF-9135]
I investigated more deeply and I noticed that:
* the first call was ALWAYS ok (maybe the first call the http-nio thread needs
to instantiate or open more things and so it delays itself)
* setting AllowChunking="true" masked the problem (and this is the reason I
found this ticket)
* setting AutoRedirect="true" also seamed to mask the issue (it could be
because it need to close the cachedOutputStream...and so it delays the null
setting on the pout)
I supposed that the issue is masked or amplified also by network setups (that
delays the threads).
* On my local machine I have a 100% failure (SocketTube), after the first
call, when I use wiremock as a backend (local network on the same machine).
* On my local machine pointing to an external server I have a 50% failure
(SocketTube) (alternatively 1 OK 1 KO ...so strange!).
* In production I also encountered the same SocketTube error... but was only
0.01% of calls... So either our crappy network is saving us right now :) ... or
there is something more I need to discover...
Here a solution (where U can see more clearly where the race problem seems to
be) ... I tried [https://github.com/vp340/cxf/tree/CXF-9135] in order to make
things deterministic and it worked 100% of times...
But... from your previous discussion I understood the problem is more a
mismatch of dependencies (use of a wrong Conduit).
[~ffang] as you suggest adding the
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-rt-transports-http-hc</artifactId>
<version>4.1.1</version>
</dependency>
solved the issue because it starts using another HttpConduit
(AsyncHTTPConduit#AsyncWrappedOutputStream).
My question so is: Am I doing something wrong with the BOM? Because Camel
(4.10.2) use by default Async CxfEndpoint from what I know and see ... but it
never import cxf-rt-transports-http-hc by default.
So by default it seems to use the wrong conduit.
And if this is true, it could be a silent big problem for a lot of
integrations.
Let me know what U think!
Cheers,
Valentino Porta
was (Author: JIRAUSER314106):
Hi [~ffang] ,
sorry to reopen this discussion.
I also came across the same race condition that [~vbeilin] described.
Experimenting on my local pc I noticed that using a Spring-Camel-Cxf BOM ...
with a local wiremock as a backend ... the first call ran smoothly ... but from
the second and beyond it always ends up with the error "SocketTube(1)
[HttpClient-1-Worker-0] Too few bytes returned by the publisher (0/206)".
Based on the indication [~vbeilin] gave above, I debug the service and also
found that there where a race condition in the
[HttpClientWrappedOutputStream.close()|https://github.com/apache/cxf/blob/main/rt/transports/http/src/main/java/org/apache/cxf/transport/http/HttpClientHTTPConduit.java#L823]
(http-nio thread ) that set to null a OutputStream pout; before the
HttpClientSizedBodyPublisher.subscribe (httpClient thread) could use it.
Here my Camel reproducer:
[https://github.com/vp340/cxf-log-example/tree/CXF-9135]
I investigated more deeply and I noticed that:
* the first call was ALWAYS ok (maybe the first call the http-nio thread needs
to instantiate or open more things and so it delays itself)
* setting AllowChunking="true" masked the problem (and this is the reason I
found this ticket)
* setting AutoRedirect="true" also seamed to mask the issue (it could be
because it need to close the cachedOutputStream...and so it delays the null
setting on the pout)
I supposed that the issue is masked or amplified also by network setups (that
delays the threads).
* On my local machine I have a 100% failure (SocketTube), after the first
call, when I use wiremock as a backend (local network on the same machine).
* On my local machine pointing to an external server I have a 50% failure
(SocketTube) (alternatively 1 OK 1 KO ...so strange!).
* In production I also encountered the same SocketTube error... but was only
0.01% of calls... So either our crappy network is saving us right now :) ... or
there is something more I need to discover...
Here a solution (where U can see more clearly where the race problem seems to
be) ... I tried [https://github.com/vp340/cxf/tree/CXF-9135] in order to make
things non-deterministic and it worked 100% of times...
But... from your previous discussion I understood the problem is more a
mismatch of dependencies (use of a wrong Conduit).
[~ffang] as you suggest adding the
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-rt-transports-http-hc</artifactId>
<version>4.1.1</version>
</dependency>
solved the issue because it starts using another HttpConduit
(AsyncHTTPConduit#AsyncWrappedOutputStream).
My question so is: Am I doing something wrong with the BOM? Because Camel
(4.10.2) use by default Async CxfEndpoint from what I know and see ... but it
never import cxf-rt-transports-http-hc by default.
So by default it seems to use the wrong conduit.
And if this is true, it could be a silent big problem for a lot of
integrations.
Let me know what U think!
Cheers,
Valentino Porta
> Second async javax call fails with allowChunking=false
> ------------------------------------------------------
>
> Key: CXF-9135
> URL: https://issues.apache.org/jira/browse/CXF-9135
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
> Affects Versions: 4.1.1, 4.1.2
> Environment: Java 17
> Reporter: Vadim Beilin
> Assignee: Freeman Yue Fang
> Priority: Major
> Fix For: 4.2.5, 4.1.10
>
> Attachments: ShowBug.java, ShowBug2.java, cxf-httpclient-bug.zip
>
>
> The second call to an asynchronous web method is failing when using the JDK
> HttpClient-based conduit and allowChunking set to false.
>
> Logs show that the while the first request has correct conetnt-length, the
> second request has Transfer-encoding: chunked, and the body is not sent at
> all. Here are 3 requests received by the server (WSDL and two web methods):
> {noformat}
> ID: 1
> Address: http://localhost:12345/Service?wsdl
> Http-Method: GET
> Content-Type:
> Headers: {Accept=[*/*], connection=[Upgrade, HTTP2-Settings],
> Content-Length=[0], Content-Type=[null], Host=[localhost:12345],
> HTTP2-Settings=[AAEAAEAAAAIAAAABAAMAAABkAAQBAAAAAAUAAEAA], Upgrade=[h2c],
> User-Agent=[Apache-CXF/4.1.1]}
> {noformat}
> {noformat}
> ID: 2
> Address: http://localhost:12345/Service
> Encoding: UTF-8
> Http-Method: POST
> Content-Type: text/xml; charset=UTF-8
> Headers: {Accept=[*/*], connection=[Upgrade, HTTP2-Settings],
> Content-Length=[152], content-type=[text/xml; charset=UTF-8],
> Host=[localhost:12345],
> HTTP2-Settings=[AAEAAEAAAAIAAAABAAMAAABkAAQBAAAAAAUAAEAA], SOAPAction=[""],
> Upgrade=[h2c], User-Agent=[Apache-CXF/4.1.1]}
> Payload: <soap:Envelope
> xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";><soap:Body><respond
> xmlns="http://test";>blah</respond></soap:Body></soap:Envelope>
> {noformat}
> {noformat}
> ID: 3
> Address: http://localhost:12345/Service
> Encoding: UTF-8
> Http-Method: POST
> Content-Type: text/xml; charset=UTF-8
> Headers: {Accept=[*/*], connection=[Upgrade, HTTP2-Settings],
> content-type=[text/xml; charset=UTF-8], Host=[localhost:12345],
> HTTP2-Settings=[AAEAAEAAAAIAAAABAAMAAABkAAQBAAAAAAUAAEAA], SOAPAction=[""],
> transfer-encoding=[chunked], Upgrade=[h2c], User-Agent=[Apache-CXF/4.1.1]}
> {noformat}
> I'm attaching a test class that demonstrates the issue.
> For the failure to happen, we need
> * to use the new default HttpClient-based conduit (URLConnection-based
> conduit works)
> * {{allowChunking}} to be set to false (not set or set to true works)
> * an asyncronous service method to be used (synchronous method works)
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
