hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: Handling idle timeout disconnect
Date Sat, 22 Feb 2014 14:52:34 GMT
On 22 February 2014 14:16, sebb <sebbaz@gmail.com> wrote:
> On 22 February 2014 14:10, Oleg Kalnichevski <olegk@apache.org> 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: dev-unsubscribe@hc.apache.org
>> For additional commands, e-mail: dev-help@hc.apache.org
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org


Mime
View raw message