commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Elwin, Martin" <>
Subject RE: [HttpClient] Automatic reconnect in case of closed connection
Date Mon, 23 Sep 2002 12:51:57 GMT
Odi (if I may call you that), thanks for the comments. Let me see if I
follow you.. :)

> Simply because there is no need for a retry in 1.0. Remember 1.0: The 
> server *always* closes the connection. So state of the 
> connection will 
> always be "closed" at the beginning of a request.

Ahh, very true, we should never be in the case with an already open
connection. But the existing retry logic for the writing of the request
doesn't care if we're in 1.0 or 1.1 mode - and it tries to do a reconnect by
closing the connection and reopening it.

> In 1.1 we have keep-alive connections but which are only kept 
> alive for 
> a certain time. So the connection may be expected open but in fact is 
> closed. Thus a retry is needed after the first attempt.

Yupp, gotcha. Unless (as noted below) we can check to see if the socket
really is alive and kicking before doing the request.

> But I am not too happy with your patch. IMHO the problem should be 
> handled by HttpConnetion and not in any higher levels.

What I found was that when a socket had been closed by the server, the write
worked, but when a read was tried an exception was thrown. If this really is
the case it's tricky to handle in the HttpConnection since the writes and
the reads are not done at the same time... A better thing would be to have a
reliable isOpen call, as you comment below.

> The problematic call in the code is: connection.isOpen()
> whose result is unfortunately not related to whether the 
> connection is 
> actually open or closed! So its return value is not well-defined.

I didn't touch this at all actually, but I noted the same thing as you say,
it's a meaningless check if the socket has been closed by the server.
> We'd better fix this HttpConnetion.isOpen() method. Do a 
> read() on the 
> input stream. Unless the connection is open -1 is returned. 
> Unfortunately read() blocks if the connection is open (and no data is 
> available)! Does available() maybe return a meaningful value? 
> This is up 
> to the implementation but should work in theory. (Haven't tried)
> Martin, could you check this possibility out please?

I'll see what I can do. :]



To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message