On 22 February 2014 14:16, sebb <[email protected]> wrote: > On 22 February 2014 14:10, Oleg Kalnichevski <[email protected]> wrote: >> On Fri, 2014-02-21 at 23:07 +0000, sebb wrote: >>> Further to the recent email about unexpected behaviour in JMeter when >>> staleCheck was disabled, the cause has been determined. >>> >>> The problem was caused by a server operating an idle timeout policy, >>> but failing to send a Keep-Alive header with the timeout information. >>> >> >> 'Keep-Alive' is a non-standard header. Web servers do not have to >> support it. > > OK, did not know that. > >>> Thus the HC code did not know that the connection would timeout, and >>> tried to re-use it. >>> This resulted in an immediate disconnect. >>> Since JMeter does not retry by default, this caused the sample to fail. >>> >>> I'm wondering whether this scenario should be handled automatically by HC. >>> It could in theory happen even with servers that send the Keep-Alive >>> header if the server and client ideas of elapsed time are not very >>> consistent. >>> >>> The idea would be to retry the request IFF the connect immediately >>> fails - i.e. before any data has been sent. >>> >>> This could not cause a problem with non-idempotent requests, as the >>> request would not actually have been sent. >>> >>> Does that sound reasonable, or is it something the app developer needs >>> to implement in a retry handler? >>> >> >> I believe we already all these features in HttpClient. All you need is >> to activate the default retry handler with retry count 1. Give it a >> shot. > > Thanks, I will try it.
That works fine. > IIRC, we disabled retries because they were causing unexpected extra > traffic to be sent to servers. > Also, generally testers need to know when requests fail, as it affects > throughput. > > So we may need our own retry handler for this specific case. Actually, it looks like there may be a bug in the DefaultHttpRequestRetryHandler class which is why it was not suitable for JMeter. We invoke it with the parameter requestSentRetryEnabled = false. However we found that additional requests were being seen at the server, so we now default to zero retries. I've just had a look at the code, and the parameter requestSentRetryEnabled seems to be applied too late. It is checked AFTER the check for idempotent requests. So a GET will be resent even if requestSentRetryEnabled is false. That does not seem right. Shall I raise a JIRA? >> Cheers >> >> Oleg >> >> >> >> --------------------------------------------------------------------- >> 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]
