Guillaume Cottenceau wrote:
What 'thing'? Abort? see HttpMethod#abort in 3.0
I was assuming stable httpclient, sorry to not making it clear before.
All right. It's true that 2.0 does not have built-in abort due to design limits.
I can't say for 3.0 but in 2.0 it seems that client.execute is blocked until the server finishes sending the headers (does make sense because executeMethod returns the HTTP response code).
Correct.
In my upper example (a server not sending any actual header) your code excerpt is blocked forever, if I'm correct.
You are.
What you could do, is the following then:
Wrap the client.execute call:
import org.apache.commons.httpclient.util.TimeoutController;
Runnable task = new Runnable() {
public void run() {
client.execute(method);
}
}
long timeout = ...; //millis
try {
TimeoutController.execute(task, timeout);
} catch(TimeoutController.TimeoutException e) {
/* task has been sent an interrupt signal by now */
}I see. HttpClient uses socket timeouts for data transfer timeouts, following your reasoning this is in the HTTP protocol?
HTTP is a connection based protocol and therefore requires a connection-aware transport layer. This is normally TCP. Timouts are available in all modern TCP implementations to prevent OS-level resource leaks. That's the reason why there is a timeout feature in Java (TCP-)Sockets.
If you don't like socket timeouts you are free to use a custom socket factory which produces sockets that behave to your taste.
Ortwin Glück
-- _________________________________________________________________ NOSE applied intelligence ag
ortwin glück [www] http://www.nose.ch software engineer hardturmstrasse 171 [pgp id] 0x81CF3416 8005 zürich [office] +41-1-277 57 35 switzerland [fax] +41-1-277 57 12
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
