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
On Friday 21 February 2003 03:28, Aurelien Pernoud wrote:
Weel, this one seems to be over (for me at least). But I'm sorry Mike, I found out my webapp was not logging httpexception correctly (I catched it and logged it in debug mode and i was only logging errors so...), I still have HttpRecoverable exception about "can't find line starting with HTTP/" with multiple users.I'm gonna check my code again, try with the old httpclient, to see the difference, and be sure of what it can come from. Aurelien Pernoud a écrit :Made a test for 45 min, seems to be going fine now. I'll test furthermore tomorrow. Aurelien Pernoud a écrit :Ok, I'm gonna test it right now and tell you tomorrow morning if everything went ok with my app. Oleg Kalnichevski a écrit :Committed--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
