hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Archie Cobbs (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HTTPCLIENT-731) Interrupting a connecting HTTP request thread incorrectly becomes a timeout exception
Date Fri, 25 Jan 2008 22:12:35 GMT

    [ 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

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
- What happens in response to a Thread.interrupt(), whatever that is, should be documented.


> 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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org

View raw message