> -----Original Message----- > From: Oleg Kalnichevski [mailto:[email protected]] > Sent: Sunday, August 01, 2010 4:47 AM > To: HttpClient User Discussion > Subject: Re: Best strategy to terminate an HttpClient (3.0.1) > connection from a background thread? > > On Thu, 2010-07-29 at 08:31 -0700, KARR, DAVID (ATTSI) wrote: > > If I had a background task that was monitoring certain conditions, > and > > it had a handle to an HttpClient object, or perhaps the Method > object, > > where the Method was still executing, what would be the cleanest way > to > > force terminate the connection from the background task, such that > the > > method execution would get a reasonable exception that could be > > interpreted as either a timeout or a force disconnect? I see the > > "HttpMethodBase.abort()" method. Would this be reasonable? > > > > Yes, it would.
Thanks for the confirmation. > > For a little more background, I'm considering this to implement a > "hard > > timeout" on HttpClient connections, as the socket timeout doesn't > really > > do that. When the system is under high load, we find that > connections > > go well over what we wanted as the "time limit" for the connection. > > We've concluded that we'd rather terminate over-long connections, > even > > if they would have normally succeeded, as we think it might help > overall > > scalability. > > > > If your main objective is scalability I am not sure if this approach is > going to help especially when using SSL connections. Neither am I. That's why I'm going to set it up to be turned on or off or tuned dynamically at runtime, so I can easily measure it's behavior during expected peak periods. Why specifically do you think this won't help for SSL connections?
