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