ffang commented on PR #3250:
URL: https://github.com/apache/cxf/pull/3250#issuecomment-5371444785

   > Sorry @ffang , just found time to get back to it, I am wondering why the 
request / socket timeouts do not trigger in this case? Did we miss something 
there? I would expect HttpClient / URLConnection to close the pipe (and stream 
consequently) upon timeout?
   
   Good question @reta — it's not something we missed, it's a genuine gap in 
the JDK APIs IMHO(no timeout for request-body write path). connectionTimeout 
only guards the pre-connect handshake (isConnectionAttemptCompleted); once 
connectionComplete is true it's never consulted again. receiveTimeout maps to 
HttpRequest.Builder.timeout() / HttpURLConnection.setReadTimeout(), both of 
which the JDK scopes strictly to reading the response — neither 
java.net.http.HttpClient nor HttpURLConnection/Socket expose any 
write/send-side timeout (Socket only has SO_TIMEOUT for reads, there's no 
SO_SNDTIMEO equivalent).
   
   Concretely, in HttpClientHTTPConduit the request body publisher drains a 
PipedInputStream via a plain blocking read on a cached-pool thread, entirely 
outside HttpClient's async exchange/selector machinery — so even if the 
response timeout were to fire, it has no handle to interrupt that pipe read; 
the exchange hasn't reached the response-wait stage yet. In 
URLConnectionHTTPConduit it's more direct: writes go straight to the 
connection's raw socket OutputStream, which the JDK never times out under any 
configuration.
   
   TimedBlockingPipe closes that gap by giving the write side its own deadline, 
reusing receiveTimeout's value since that's the property users already 
configure — rather than inventing a new config property for something that's 
really the same "how long am I willing to wait for this exchange" intent.
   
   Best Regards
   Freeman


-- 
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