hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aurelien Pernoud" <apern...@sopragroup.com>
Subject RE: [PATCH] Fix for bug 16458
Date Mon, 24 Feb 2003 15:02:50 GMT

Wow sorry I missed the end of this conversation !

If I understand well, the "new" trouble doesn't come from connectionManager,
even if it throws the same exception, but from the fact that the connection
was lost, for some external reason, after writing the request but before
reading the response ?

Before fix for bug 16458, the request was auto-retried, but isn't anymore
due to the "trick" used before to retry the request. Am I right ?

I don't know if the retry must only be in httpclient, personnally I'd like
it on method directly, but maybe with a possibility of disabling the retry,
as Sam said.

Doesn't this mean the pending release as the "auto-retry" feature broken in
the case I'm talking above ?

Michael Becke a écrit :

> Sam,
>
> I quite agree.  This could very well be what is happening for
> Aurelien.
>
> One question.  Why is there no error when writing the request, but
> only when reading the response?  When I let the connection time out I
> always get a HttpRecoverableException in writeRequest().  This
> exception is caught and the method is retried.
>
> Mike
>
> Sam Maloney wrote:
>> Hi,
>>
>> This is what I have found, as I have worked in that area now:
>>
>> The exception you speak is caused by fix for 16458. Before, instead
>> of said exception, you would have got 100% CPU * forever.
>>
>> Here is the source of the exception (HttpMethodBase.java):
>>
>> <SNIP>
>> protected void readStatusLine(HttpState state, HttpConnection conn)
>>     throws IOException, HttpRecoverableException, HttpException {
>>         LOG.trace("enter HttpMethodBase.readStatusLine(HttpState,
>>         HttpConnection)"); //read out the HTTP status string
>>         String statusString = conn.readLine();
>>         while ((statusString != null) &&
> !statusString.startsWith("HTTP/")) {
>>             statusString = conn.readLine();
>>         }
>>         if (statusString == null) {
>>             // A null statusString means the connection was lost
>>             before we got a // response.  Try again.
>>             throw new HttpRecoverableException("Error in parsing the
>>                 status " + " line from the response: unable to find
>>                 line starting with" + " \"HTTP/\"");
>>         }
>> 	...
>> </SNIP>
>>
>> Before fix for 16458, is was impossible to have a return value of
>> null from readLine(). Only an empty string would be returned.
>>
>> The comment says the correct thing here, that the author expeced
>> null return to signify connection reset by peer/incorrect response.
>>
>> The comment implies that somewhere up the call stack, the
>> HttpRecoverableException will be caught and the request automatically
>> retried, but I noticed it doesn't. Instead the exception gets to the
>> main thread.
>>
>> I'm not sure if the code just hasn't been written to auto retry the
>> request when an HttpRecoverableException, or if it is broken, or if
>> this is the way intended, for the onus to be on the user of
>> HttpClient to catch the exception and try the request again. I'm
>> sure someone more experienced with HttpClient can answer that.
>>
>> I think what makes sense as to what should happen is that any
>> auto-retry code (and remember, the HTTP RFC says only to retry
>> once!) should be in HttpClient.java. If the user uses the
>> HttpConnection and HttpMethod classes directly, then it would be up
>> to the user to retry if they wanted to.
>>
>> As for you Aurelien, you can simpy wrap your call to
>> HttpClient->executeMethod() like this:
>>
>> for(int tries = 1; tries <= 2; tries++){
>> 	try{
>> 		client.executeMethod(...);
>> 		break; // If success (no exception), then break.
>> 	}catch(HttpRecoverableException re){
>> 		if(tries == 2){
>> 			throw re; // If this was try 2, then give up.
>> 		}
>> 	}catch(IOException ioe){
>> 		throw new RuntimeException(".....", ioe);
>> 	}
>> }
>>
>> To HttpClient developers:
>> That above part of code should probably be put into HttpClient, as
>> if the user is using HttpClient, I think a recoverable error like
>> the socket closing or bad response should be auto retried, perhaps
>> have a setting on HttpClient (enableAutoRetry(bool) or something.)
>>
>> Later,
>> Sam Maloney


Mime
View raw message