hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roland Weber (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 19:47:34 GMT

    [ https://issues.apache.org/jira/browse/HTTPCLIENT-731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12562634#action_12562634

Roland Weber commented on HTTPCLIENT-731:

Hello Archie,

support for interrupts is lacking in HttpClient 3.1 connection management all over the place.
We don't have an InterruptedException in the connection manager interface, so we are mapping
those exceptions to timeout exceptions. Have a look at HTTPCLIENT-633 to learn of another

HttpClient 3.1 is in maintenance mode, bug fixes only. Screwed design is bad, but not a bug.
Documenting the behavior is a good idea, but I don't see a point in trying to change it. The
issues of HTTPCLIENT-633 are already fixed in HttpClient 4.0 trunk and iirc the TimeoutController
was a workaround for implementing connection timeouts on 1.2 JVMs which is no longer needed
in the new codebase. Actually, it is not even needed in the old codebase if you're on Java
1.4 or later. There is some reflection magic that should use the timeout threads only when
there is no Socket constructor that supports timeouts:

I fail to see why converting an interrupt to an IOException is less bogus than converting
it to a TimeoutException. Would it help you if the TimeoutException had a "thread interrupted"
message that you could check for?


> 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