Clarify behavior of new HttpClient responseTimeout parameter
Basics
Logistics
Basics
Logistics
Description
HttpClient added a parameter responseTimeout in their 5.0. It is documented as:
/**
* Determines the timeout until arrival of a response from the opposite
* endpoint.
* <p>* A timeout value of zero is interpreted as an infinite timeout.
* </p>* <p>* Please note that response timeout may be unsupported by
* HTTP transports with message multiplexing.
* </p>* <p>* Default: {@codenull}* </p>*
* @since 5.0
*/
It’s not clear what “arrival of a response” actually means: The beginning of the receipt of the response header? The complete receipt of the header and/or body? Other?
Will ask for clarification on the HC users list and go from there. If it’s not what we want, then we may have to consider implementing the end-to-end request cap with the async approach we’ve already discussed.
Unfortunately it’s as I suspected. It’s just a timeout waiting on the response head. He says “It is basically nothing more than a socket timeout.” And there is no overall cap like Scott wants. There is a brief mention that the behavior may change in the future.
So if we want the overall absolute timeout, we’ll have to implement it. The good news is I already did it and it’s 90% done. Just needs builder support and then testing.
HttpClient
added a parameterresponseTimeout
in their 5.0. It is documented as:/** * Determines the timeout until arrival of a response from the opposite * endpoint. * <p> * A timeout value of zero is interpreted as an infinite timeout. * </p> * <p> * Please note that response timeout may be unsupported by * HTTP transports with message multiplexing. * </p> * <p> * Default: {@code null} * </p> * * @since 5.0 */
It’s not clear what “arrival of a response” actually means: The beginning of the receipt of the response header? The complete receipt of the header and/or body? Other?
Will ask for clarification on the HC users list and go from there. If it’s not what we want, then we may have to consider implementing the end-to-end request cap with the async approach we’ve already discussed.