Hello Oleg,
I think it's a bit more complicated ... Let me explain it:
- we have a pool with a response timeout of 15s
- this pool is shared by 2 webservices, ws1 and ws2. Ws1 uses the pool's
response timeout, but ws2 uses its own response timeout of 10s.
- the webservice ws2 has 2 methods, m1 and m2, m1 uses the ws2 timeout but m2
uses its own response timeout of 12s.
- and finally the method m2 is used by 2 clients, c1 and c2. c1 is a very good
client so his response timeout is 20s, and c2 is very bad so he only has a 3s
response timeout.
When we set the response timeout at request level, we do this:
/**
* This method sets the 'responseTimeout' to this http method.
*
* @param RequestBuilder the 'RequestBuilder' object
* @param responseTimeout the response timeout to apply
* @return none
*/
private void setTimeout(RequestBuilder rb)
{
// 1. If the client has a timeout (clientResponseTimeout != -1), then set
this value
// 2. If the client has no timeout but the method has, then set this value.
// 3. If the method has no timeout but the api has, then set this value.
// 4. Otherwise set the pool's response timeout.
int clientResponseTimeout =
this.objClient.getResponseTimeout(this.objCall.getId());
int responseTimeout = (clientResponseTimeout != -1 ? clientResponseTimeout :
(this.objCall.getResponseTimeout() != -1 ? this.objCall.getResponseTimeout() :
(this.objInterface.getResponseTimeout() != -1 ?
this.objInterface.getResponseTimeout() : this.objHttp.getResponseTimeout())) );
rb.setConfig(RequestConfig.copy(this.objHttp.getRequestConfig()).setSocketTimeout(responseTimeout).build());
}
And that's my problem now. Do you think this can be solved in any way using
http5?
Thanks,
Joan.
-----Mensaje original-----
De: Oleg Kalnichevski [mailto:ol...@apache.org]
Enviado el: viernes, 19 de octubre de 2018 18:22
Para: HttpClient User Discussion
Asunto: Re: Migration from Async 4.1.3 to HttpClient 5
On Fri, 2018-10-19 at 18:01 +0200, Joan Balagueró wrote:
> Hi Oleg,
>
> Thanks a lot for all your answers. I'll work on this a bit more.
>
> There is just one problematic thing for us. Our app is an api gateway,
> and one important piece is the response timeouts between our app and
> the client application servers. If fact, it's common the user changes
> these response timeouts from the admin console.
>
> If now they cannot change them on the fly, that means stopping the
> http pool, recreating the ioreactor with the new timeout and starting
> the pool again, even if this takes just several seconds is something I
> cannot do with installations that are processing more than 15.000
> requests per second.
>
> The main purpose to move to HttpClient5 is the http pool with Lax Max
> connections (PoolConcurrencyPolicy.LAX), because we were detecting
> contention on the current pool due to the global lock. We don't need
> HTTP/2 so, from my ignorance, is there any way to use a Lax Pool with
> http1.1 in order to get this socket timeout at request level?
>
No, there is not. There will be no request level socket timeout override in HC
5.0 because even with HTTP/1.1 it makes no sense when messages are being
pipelined.
HC 5.0 could however provide APIs to enumerate all open connection and let
their socket timeout get re-set. Feel free to raise a change request for this
feature or better yet contribute it.
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
For additional commands, e-mail: httpclient-users-h...@hc.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
For additional commands, e-mail: httpclient-users-h...@hc.apache.org
