You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "Elwin, Martin" <me...@rsasecurity.com> on 2002/09/23 13:22:57 UTC
RE: [HttpClient] Automatic reconnect in case of closed connection
.
Better might be to move the readResponse(...) call done in
processRequest(...) into the retry mechanism used for the writeRequest(...)
call instead of adding a retry on another (in this case higher) level, which
was my first suggestion. Currently it looks like the HttpClient is supposed
to handle a closed socket - a HttpRecoverableException is thrown in the
readStatusLine(...) method - but since no retry is done for the reading it
will never handle that problem automatically.
So, modified version might look like:
private void processRequest(HttpState state, HttpConnection connection)
throws HttpException, IOException {
log.trace(
"enter HttpMethodBase.processRequest(HttpState,
HttpConnection)");
//try to do the request
int retryCount = 0;
do {
retryCount++;
if (log.isTraceEnabled()) {
log.trace("Attempt number " + retryCount + " to write
request");
}
try {
if (!connection.isOpen()) {
log.debug("Opening the connection.");
connection.open();
}
writeRequest(state, connection);
readResponse(state, connection);
used = true; //request worked, mark this method as used
break; //all done
} catch (HttpRecoverableException httpre) {
log.info("Recoverable exception caught when doing request");
if (log.isDebugEnabled()) {
log.debug("Closing the connection.");
}
connection.close();
if (retryCount == maxRetries) {
log.warn(
"Attempt to do request has reached max retries: "
+ maxRetries);
throw httpre;
}
}
} while (retryCount <= maxRetries);
//everything should be OK at this point
}
... or similar...
Ortwin, not sure if I understand why a retry only should be done for 1.1.
Would you mind elaborating on the reasons for that? The current retry logic
is valid for both 1.0 and 1.1, as far as I can tell.
Thanks a lot!
Regards,
/M
Ortwin Glück wrote:
> But only for HTTP/1.1
>
> Jeff Dever wrote:
> > This seems reasonable to me.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [HttpClient] Automatic reconnect in case of closed connection
Posted by Ortwin Glück <or...@nose.ch>.
Elwin, Martin wrote:
> Ortwin, not sure if I understand why a retry only should be done for 1.1.
> Would you mind elaborating on the reasons for that? The current retry logic
> is valid for both 1.0 and 1.1, as far as I can tell.
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.
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.
But I am not too happy with your patch. IMHO the problem should be
handled by HttpConnetion and not in any higher levels.
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.
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?
Kind regards
Odi
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>