On Sat, 2016-01-02 at 14:33 -0500, Benson Margulies wrote: > On Sat, Jan 2, 2016 at 2:26 PM, Oleg Kalnichevski <ol...@apache.org> wrote: > > On Sat, 2016-01-02 at 14:13 -0500, Benson Margulies wrote: > >> I somehow convinced myself that socketTimeout was for some socket > >> operation, not for the overall 'have we received a response to this > >> request'. > >> > >> I may offer you a doc patch. > >> > > > > Benson, > > > > SocketTimeout parameter defines maximum period of inactivity between i/o > > events. So, in other words it is more like 'has there been any activity > > on this connection'. > > I think I follow. If the server never answers, we'll hit this timer > and that's that. However, what if the server keeps sending dribbles of > content but we never receive a complete retry? In plain old sync mode, > I thought I saw a plain 'timeout' parameter, which (I assumed) did > what I was looking for. In practical terms, does the socket timeout > end up serving the purpose?
What you are probably referring to is also known as a response deadline or an execution deadline. Neither classic i/o nor non-blocking i/o transports currently support them. There is a feature request, though, I am not sure it will ever get implemented. https://issues.apache.org/jira/browse/HTTPCLIENT-1074 However in most cases socket timeout (or inactivity timeout) should be good enough. What you probably what to avoid is a request blocking indefinitely due to the server's not sending any data. Inactivity timeout will serve the purpose. If you want to prevent the server sending dribbles of rubbish you might be better off looking at the actual content. > > My application here is a JAX-RS server that uses async http components > to submit tasks to workers. I could set timeouts on the jax-rs > requests, but then I'd need some way to (safely) cancel > possibly-pending async http transactions. May I call cancel on the > returned future from execute for this purpose? > Canceling the request future will unblock any consumer thread blocked on it but will not cancel the ongoing message exchange. If you want to have full control over request execution / response handing you should consider using custom HttpAsyncRequestProducer / HttpAsyncResponseProducer implementations. Hope this helps Oleg > > > > > Does this make sense? > > > > Oleg > > > > > >> > >> On Sat, Jan 2, 2016 at 12:12 PM, Oleg Kalnichevski <ol...@apache.org> > >> wrote: > >> > On Fri, 2016-01-01 at 16:04 -0500, Benson Margulies wrote: > >> >> I've spent some time reading the code, and I'm stumped as to how to > >> >> arrange for a timeout on getting a response back with the async > >> >> client. I see how to configure the connect timeout with RequestConfig. > >> >> I'm on 4.4.1. I'm using callbacks, not the returned futures, so it > >> >> would be some coding to make my own arrangements. > >> >> > >> > > >> > Hi Benson > >> > Should not RequestConfig#socketTimeout be what you want? > >> > > >> > 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
