[
https://issues.apache.org/jira/browse/HTTPCLIENT-731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12562714#action_12562714
]
Archie Cobbs commented on HTTPCLIENT-731:
-----------------------------------------
If this stuff is addressed in 4.0 that's fine with me. I was only trying to
bring attention to the issue but it sounds like it's already being addressed in
which case feel free to close out this bug.
I have worked around the problem in my own code so there's no urgency for a 3.x
fix on my part.
My only general big picture comments:
- It would be nice if Thread.interrupt() could be used by any part of an
application to abort an in-progress HTTP request. Some applications use
Thread.interrupt() as a general "stop what you're doing" mechanism (for better
or worse) when there are blocking tasks involved. Of course this means methods
declaring 'throws InterruptedException', etc. I'm sure this feature is
debatable.
- What happens in response to a Thread.interrupt(), whatever that is, should be
documented.
Thanks!
> Interrupting a connecting HTTP request thread incorrectly becomes a timeout
> exception
> --------------------------------------------------------------------------------------
>
> Key: HTTPCLIENT-731
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-731
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Components: HttpClient
> Affects Versions: 3.1 Final
> Environment: Java 1.5 Linux
> Reporter: Archie Cobbs
> Attachments: HTTPCLIENT-731.2.txt, HTTPCLIENT-731.txt
>
>
> Consider this logic in {{TimeoutController.java}}:
> {noformat}
> public static void execute(Thread task, long timeout) throws
> TimeoutException {
> task.start();
> try {
> task.join(timeout);
> } catch (InterruptedException e) {
> /* if somebody interrupts us he knows what he is doing */
> }
> if (task.isAlive()) {
> task.interrupt();
> throw new TimeoutException();
> }
> }
> {noformat}
> The effect of this is that if thread A is in the middle of performing an HTTP
> request and happens to be waiting for the socket to connect, and then thread
> B interrupts thread A, thread A will throw a {{TimeoutException}}, even if
> the actual timeout is far off in the future.
> In other words, interrupting a requesting thread that happens to be waiting
> for a socket to connect is incorrectly interpreted as a connection timeout,
> which is incorrect.
> In my application, this causes the client to incorrectly believe the server
> is down, when in actuality some other part of the client is simply trying to
> cancel an outstanding RPC request.
> I realize that invoking {{HttpMethodBase.abort()}} would be a better way to
> abort the RPC request and am working on refactoring my code to do that.
> However, this "translation" of a thread interruption into a timeout event is
> still incorrect. Furthermore, this behavior is undocumented AFAICT.
> Suggestion for improvement: Convert thread interruptions into the equivalent
> of {{abort()}} and document this behavior.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
