vp340 opened a new pull request, #3660:
URL: https://github.com/apache/cxf/pull/3660

   Hi everyone,
   
   I think we have a similar problem as the 
https://issues.apache.org/jira/browse/CXF-9135 also in the 
HttpClientHTTPConduit.HttpClientBodyPublisher . 
   
    
   Let me explain.  (see the https://issues.apache.org/jira/browse/CXF-9267 for 
the attachments).
   
   I noticed that a race condition can happen where the [caller thread] close 
the HttpClientBodyPublisher.close ...that set the stream=null ... and then the 
[http client thread] try to subscribe to it... but finding stream==null it gets 
a noBody() ... resulting in a "SocketTube(1) [HttpClient-1-Worker-0] Too few 
bytes returned by the publisher (0/241)" Exception ... that covers the real 
error (Connection Timed out). 
   
    
   I noticed experimentally that this happens when :
   
   - AllowChunking="true" in the Conduit
   
   - payload are under chunkingThreshold (<4096) ... (I managed to replicate 
only this scenario... I don't know for sure that also other are affected)
   
   - Connection Timeout happens to be set as EXACTLY the value of the real 
network delay
   
   Before I said 'EXACTLY' because (see histogram.png) I run some test pointing 
to a free mock services online (thanks for the help 
[https://app.beeceptor.com](https://app.beeceptor.com/)) ...) ...in order to 
simulate some latency (my local wiremock was too fast and I had to set timeout 
at 1/2 ms ).
   
   The real latency of the network was 180ms ... (see the reproducer under to 
get command) .
   
   If I set connection timeout...I get that type of errors:
   
   10<<180:
    Could not send Message.
   HTTP connect timed out
   
   180 ≃ 180
   Could not send Message.
   HTTP connect timed out
   request timed out (...I have no idea why and where this was thrown...but yes)
   SocketTube(1) [HttpClient-1-Worker-0] Too few bytes returned by the 
publisher (0/241)
   SSLTube(SocketTube(5)) stream=1 [HttpClient-1-Worker-0] Too few bytes 
returned by the publisher (0/241)
   
   1000 >> 180 :
   OK 200
   
   Our race conditions are:
   
   SocketTube if I was using "http".
   SSLTube(SocketTube(5)) if I was using "https".
   
   
   I also add some new tests.... especially "testSubscribeAfterPublisherClose" 
failed with the code before.
   Let me know what U think. 
   
   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]

Reply via email to