Thanks Oleg. In the meantime I wrote some tests that confirm what you say.
Thanks, Dan ----- Original Message ---- From: Oleg Kalnichevski <[email protected]> To: HttpClient User Discussion <[email protected]> Sent: Friday, 12 February, 2010 21:36:57 Subject: Re: Blocking releaseConnection when server still sending data Dan Gravell wrote: > Hi. This is a question for HTTPClient 3.1. I am writing an app that needs to > enforce a maximum overall time in which a http GET method can be opened, read > and released. Even if a server is sending me data and the timeout is hit, I > want to abort the transfer. > > I am using the MultiThreadedHttpConnectionManager. > > After executing, I check the status code. If it's not 200 the effect is that > I call releaseConnection() immediately. However, I have noticed that calling > releaseConnection() blocks until the server has finished sending data. For > instance, it may respond with a 400 and then slowly stream back a response > body. Thus, my 'maximum overall timeout' may be compromised. > > I had wondered whether an alternative may be to schedule a Runnable in the > future for the timeout which, when run, calls abort() on the Method. Two > concerns: > > 1) Would this forcibly terminate the transfer? Yes, it would. > 2) What would be the effect on MultiThreadedHttpConnectionManager? > As long as you always call HttpMethod#releaseConnection() for all methods (preferably from a finally clause) there should no problem with the MultiThreadedHttpConnectionManager Oleg PS: consider upgrading to HttpClient 4.0 > Many thanks for any guidance you can give me. > > Dan > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
