[
https://issues.apache.org/jira/browse/HTTPCLIENT-731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roland Weber closed HTTPCLIENT-731.
-----------------------------------
Resolution: Won't Fix
Hello Archie,
I hope that 4.0 will satisfy your requirements. If it doesn't, feel free to
open new issues.
The ClientConnectionManager does declare InterruptedException for all blocking
operations:
http://hc.apache.org/httpcomponents-client/httpclient/apidocs/org/apache/http/conn/ClientConnectionManager.html#getConnection(org.apache.http.conn.HttpRoute)
Interrupts during normal IO operations should be mapped by JVM classes to
InterruptedIOException:
http://java.sun.com/j2se/1.5.0/docs/api/java/io/InterruptedIOException.html
Funny to see that SocketTimeoutException is a subclass of
InterruptedIOException :-)
Still, the preferred way to abort request execution in 4.0 is by calling
request.abort():
http://hc.apache.org/httpcomponents-client/httpclient/apidocs/org/apache/http/client/methods/AbortableHttpRequest.html
I guess we'll have to add some thread interrupt mechanism there to abort if the
request is blocked waiting for a connection.
cheers,
Roland
> 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]
