Details
-
Improvement
-
Status: Closed
-
Major
-
Resolution: Won't Fix
-
3.1 (end of life)
-
None
-
None
-
Java 1.5 Linux
Description
Consider this logic in TimeoutController.java:
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(); } }
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.
Attachments
Attachments
Issue Links
- is related to
-
HTTPCLIENT-734 request.abort() should interrupt thread waiting for a connection
- Closed