|
If you were logged in you would be able to see more operations.
|
|
In attempting to build a UI that allows a user to cancel a long running task (e.g. replicating a large repository using HTTP connections), I discovered a flaw in the HTTPClient; it's releaseConnection() method attempts to consume the remaining response body, which can take many minutes if the thread was interrupted during a large query response. I've attached a patch for releaseConnection() that checks if the current thread is interrupted; if so, it calls method.abort(), which returns promptly, sacrificing the reusable connection, otherwise it uses the existing logic to ensure the connection can be reused.
|
|
Scheduling for 2.2.4.
Instead of checking for the interrupted status, HTTPClient no longer tries to read any remaining bytes from the response stream. All example code seems to indicate that simply calling method.releaseConnection() is the appropriate way to deal with connections.
"I've reopened this because the offered solution doesn't fix the behavior - the releaseConnection method of the underlying commons HTTPMethod also attempts to read the remaining bytes in the connection. Using abort() as I originally suggested, when the thread is interrupted, is appropriate use of the commons HTTP API in this situation." -- Alex Vigdor
The isInterrupted() check has been added to HTTPClient.
|
|
Bug
Resolved
Major
HTTPClient does not respond appropriately when thread is interrupted
