Hi Oleg, Thanks! I'll try it asap
Joan. -----Mensaje original----- De: Oleg Kalnichevski [mailto:ol...@apache.org] Enviado el: martes, 23 de octubre de 2018 9:28 Para: HttpClient User Discussion Asunto: Re: Migration from Async 4.1.3 to HttpClient 5 On Mon, 2018-10-22 at 20:40 +0200, Joan Balagueró wrote: > That would be great. > Thanks Oleg. Hi Joan I added #responseTimeout to RequestConfig that will work the same way as socket timeout in 4.1 for HTTP/1.1 transport https://github.com/apache/httpcomponents-client/commit/75ca519314b783ba0d314e84f3a7e3488a7c968c Oleg > > -----Mensaje original----- > De: Oleg Kalnichevski [mailto:ol...@apache.org] Enviado el: domingo, > 21 de octubre de 2018 13:11 > Para: HttpClient User Discussion > Asunto: Re: Migration from Async 4.1.3 to HttpClient 5 > > On Sat, 2018-10-20 at 20:23 +0200, Joan Balagueró wrote: > > Ok, I understand whtat you mean. Since this is a non-blocking model > > when we send the request the thread is released, so I simply have to > > count the time passed from I send the response until the > > 'responseReceived' method is invoked, and if this time has been > > exceeded just throw an exception (and avoid read the response body > > content). > > > > Thanks, > > Joan. > > > > Hi Joan > > That will likely require an observer thread and creating a thread per > request can be expensive. > > I will see if there is a way provide a socket timeout per request > setting for HTTP/1.1 transport only without exposing the same setting > to HTTP/2 transport. > > Oleg > > -----Mensaje original----- > > De: Oleg Kalnichevski [mailto:ol...@apache.org] Enviado el: sábado, > > 20 > > de octubre de 2018 18:17 > > Para: HttpClient User Discussion > > Asunto: Re: Migration from Async 4.1.3 to HttpClient 5 > > > > On Fri, 2018-10-19 at 21:07 +0200, Joan Balagueró wrote: > > > 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()). > > > se > > > tS > > > ocketTimeout(responseTimeout).build()); > > > } > > > > > > And that's my problem now. Do you think this can be solved in any > > > way using http5? > > > > > > > I must admit I do not understand the reason for doing all that in > > the first place. I also do not understand what exactly you mean by > > response timeout. Max waiting time until a response head is > > received? > > > > 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 > > > > > --------------------------------------------------------------------- > 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 > --------------------------------------------------------------------- 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
