Thanks for the pointers, this does seems similar to what I was thinking of. My understanding is that this is currently not possible with the http async client at the moment. Applying this logic to the httpasyncclient would mean dynamically change the route max connection depending on how well they behave. Is that right ?
Thomas 2015-05-08 9:46 GMT+02:00 Oleg Kalnichevski <[email protected]>: > On Thu, 2015-05-07 at 11:22 +0200, Thomas Boniface wrote: > > Hi, > > > > I have an application that receives and HTTP request from a user and > > contact multiple external servers. When each external server responded > (or > > the servlet timeout is reached) and HTTP response is built based on > > external servers responses. > > > > I think in such a case, when one of the external server is having trouble > > to respond as fast as it should my application will become less and less > > responsive: as it will wait to reach servlet timeout to respond to the > > client and other client request still incoming will experience the same > > problem. > > > > Thinking on how to prevent such cases, I started thinking of ways to > > decrease the number of requests made to route having bad performances (by > > implementing an exponential backoff mechanism for instance) but it came > to > > my mind that it may be possible to prevent this just by modifying the > pool > > configuration. My idea would be to greatly decrease the connection > request > > timeout (setConnectionRequestTimeout), my understanding is if the http > > async client cannot send the request within say 5ms it probably means the > > route is currently overloaded. > > > > Is this the right approach to solve this type of scenario ? > > > > Thanks, > > Thomas > > Thomas > > HttpClient ships with a so called AIMD back-off manager > > http://hc.apache.org/httpcomponents-client-4.4.x/httpclient/apidocs/org/apache/http/impl/client/AIMDBackoffManager.html > > http://hc.apache.org/httpcomponents-client-4.4.x/httpclient/apidocs/org/apache/http/impl/client/DefaultBackoffStrategy.html > > You probably might be able to use it (or some custom implementation) for > your purpose. > > Oleg > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
