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?
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. Even if I could have the background task terminate the connection cleanly, I'm not certain this will help our situation, and determining whether it will help before it gets to production will be difficult. When the system is under high load, things tend to be a little chaotic :) . I might find that my background task doesn't get enough time to run, or it might end up making the other tasks take longer. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
