[
http://issues.apache.org/jira/browse/HTTPCLIENT-596?page=comments#action_12426904
]
Arnaud Masson commented on HTTPCLIENT-596:
------------------------------------------
Ortwin:
The code that requests aborting a composite operation don't have to know the
details.
In the implementation of the background task, you can put the cleanup in a
finally{} block.
It will automatically be called if the thread is interrupted (that's why I
consider the interrupt() method as "safe").
try {
httpClient client = ...
client.execute(method);
...
}
finally {
// error *or interrupted*
// do the cleanup: rollback transactions, free resources correctly, shutdown
channels...
}
In fact the finally{} block may already exist for normal error handling.
Why Thread pools are not recommended ?
Oleg,
If the http code is not directly in the Thread class, but in a nested method
call, then you have to write code like that:
class OtherClass {
void sendMessage(String url) {
HttpClient client = ...
WorkerThread currentWThread = null;
if (currentThread instanceof WorkerThread)
currentWThread = (WorkerThread)currentThread;
HttpMethod method1 = ...
if (currentThread != null )
currentWThread.setCurrentMethod(method1 );
try {
client.execute(method);
}
finally {
if (currentThread != null )
currentWThread.setCurrentMethod(null);
}
...
HttpMethod method2 = ...
...
}
}
Otherwise (if you want to avoid the cast) you must pass the WorkerThread or a
special interface to each method that may perform HTTP operations.
Moreover you don't always control the creation of the thread that call your
code.
I understand that you don't want to change this in HttpClient 3.
My fix outside HttpClient works for me but I believed that other people may
have the same difficulties, especially in a swing app with long requests.
If HttpClient 4 can use NIO, it may have the behavior I am requesting, since
the JDK doc says about interrupt():
"If this thread is blocked in an I/O operation upon an interruptible channel
then the channel will be closed, the thread's interrupt status will be set, and
the thread will receive a ClosedByInterruptException."
I just hope that ClosedByInterruptException will not be catched and ignored.
Thanks!
> read() on the stream returned by HttpMethod.getResponseBodyAsStream() cannot
> be simply canceled with Thread.interrupt
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: HTTPCLIENT-596
> URL: http://issues.apache.org/jira/browse/HTTPCLIENT-596
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient
> Affects Versions: 3.0 Final, 3.0.1
> Environment: Windows XP
> Reporter: Arnaud Masson
>
> I have a working thread that needs to download some big file with
> HttpMethod.getResponseBodyAsStream().
> A swing component displays a progress indication and has a "stop" button.
> When the stop button is clicked by the user, I would like to stop the
> download as soon as possible, so I call interrupt() on the working thread
> from the EDT, which should throw an InterruptedException or
> InterruptedIOException inside the working thread.
> But the read() operation on the stream returned by
> HttpMethod.getResponseBodyAsStream() is not interrupted.
> The working thread stacktrace is:
> SocketInputStream.socketRead0(FileDescriptor, byte[], int, int, int)
> //<--------- blocking
> SocketInputStream.read(byte[], int, int) line: 129
> BufferedInputStream.fill() line: 218
> BufferedInputStream.read() line: 235
> ChunkedInputStream.getChunkSizeFromInputStream(InputStream) line: 249
> ChunkedInputStream.nextChunk() line: 220
> ChunkedInputStream.read(byte[], int, int) line: 175
> AutoCloseInputStream(FilterInputStream).read(byte[], int, int) line:
> 111
> AutoCloseInputStream.read(byte[], int, int) line: 107
> ...
> I know that the JRE SocketInputStream doesn't support interrupt() but
> HttpClient should hide this problem.
> A workaround is to use request.abort() but it should be possible to cancel a
> thread without knowing on what it is blocked.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
