[
http://issues.apache.org/jira/browse/HTTPCLIENT-596?page=comments#action_12426890
]
Arnaud Masson commented on HTTPCLIENT-596:
------------------------------------------
I agree, it is impossible to cancel directly Socket.read(),
That 's why I have suggested using a thread pool (see my previous comment
aboutCancelableOutputStream).
The caller would be blocked on a join() which supports Thread.interrupt().
It works great for me but I have to maintain wrappers for all calls to
HttpClient.
I think it is not necessary to add new classes like Abortable. Thread has
already interrupt() and it works for several operations: Thread.join(),
Thread.sleep(), Future.get(), etc.
This is the standard way to cancel a blocked thread. (And this is safe unlike
Thread.stop())
Why reinvent the wheel?
Runnable r = new Runnable() {
public void run() {
...
Thread.sleep(1000); //1
...
otherThread.join(); //2
...
Future f = ...
executor.submit(f);
f.get(); //3
...
HttpClient client = ...
client.execute(...) //4
...
}
Thread myThread = new Thread(r);
...
If I want to cancel myThread, I don't know which is the current blocking
operation (1) (2) (3) or (4).
If the program execution is at (1) or (2) or (3), interrupt() works well, but
if it is at (4), interrupt() is ignored.
So (4) is not consistent with other kinds of blocking operations.
> 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]
