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>