[ 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]