reta commented on PR #3250: URL: https://github.com/apache/cxf/pull/3250#issuecomment-5387653561
> 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). Got it, thanks @ffang , I reviewed the implementation a few times, and I think got a good understanding what it does. From other side, it adds a lot of complexity with re-implementing pipes with notify / await, it really opens up a whole new class of issues (we spent a lot of time patching HttpClientHTTPConduit). And you are certainly right about `HttpRequest.Builder.timeout()` (it is not scoped to request), as an alternative I was thinking why don't we suggest switching the HTTP client conduit for cases where JDK's `HttpClient` just has gaps? We do have Netty / AHC 4 / AHC 5 which, AFAIK, do handle such cases better? Wdyt? PS: Still looking if we could have simpler implementation, @coheigea wondering if you could find time to take a look as well? The change will impact basically all default clients, thanks. -- 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]
