On Sat, Jan 2, 2016 at 3:42 PM, Oleg Kalnichevski <ol...@apache.org> wrote: > 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.
Since I own the server, I think I'll stick to the socket timeout. > >> >> 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 Definitely. > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org
