vp340 commented on PR #3640:
URL: https://github.com/apache/cxf/pull/3640#issuecomment-6453756109
Hi @ffang ,
Thanks a lot for your accurate analysis and explanation !
> With this PR the publisher keeps its own reference to the buffered body,
so the order of the two threads no longer matters. Once it's in, you shouldn't
need cxf-rt-transports-http-hc or AllowChunking=true as a workaround.
Sure thanks! Being the error cases in production so low we will update to
the next 4.1.10 (or 4.2.5) not with a rush. I believe things have been this way
for years (way before I even start working) and no one has ever complained
about that ...till I discover the problem during local tests.
: /
> In the old code, the body was sent only if the HttpClient finished all of
that before the caller dropped the buffer. If it was too late, it got either
0/206 ("Too few bytes returned by the publisher") or a chunked request with no
body. Which thread wins depends on:
- whether the connection is new or reused, and the latency to open it;
_**(in production this should slow down the httpClient thread )**_
- how long the headers take to write _**(in production this should take more
time... so slow down the httpClient thread)**_ ;
- how much of the body was already buffered when the send started;
- JIT warm-up; _**(in production this should be already the hottest things
running on our ocp ... so this could favor both http-nio or httpClient threads
...)**_
- thread scheduling and load on the machine. _**(this also can be
non-deterministic in a production environment)**_
So all this things or go againt the httpClient thread (so more error) or
should affect both thread . A such big difference in failure rate is quite sus,
so probably the last 2 points are the ones that influence the most and decide
to let the httpClient thread win (for our sake) .
Thanks a lot for all the excellent job 👍 ... if U need anything I'm here to
help.
Have a great day!
Cheers,
Valentino Porta
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
