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]
