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 Mon, 24 Feb 2014 01:47:41 GMT
On 24 February 2014 00:40, sebb <sebbaz@gmail.com> wrote:
> On 22 February 2014 17:23, sebb <sebbaz@gmail.com> wrote:
>> On 22 February 2014 16:37, Oleg Kalnichevski <olegk@apache.org> wrote:
>>> On Sat, 2014-02-22 at 14:52 +0000, sebb wrote:
>>>
>>> ...
>>>
>>>> > 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?
>>>>
>>>
>>> DefaultHttpRequestRetryHandler implementation goes back to the dark ages
>>> of HttpClient 2.x, but I think it was always intended to work that way.
>>> So, it is a feature.
>>
>> I've also now checked the User Guide, which says:
>>
>> * HttpClient will automatically retry those methods that are assumed
>> to be idempotent.
>> * HttpClient will automatically retry those methods that fail with a
>> transport exception while the HTTP request is still being transmitted
>> to the target server (i.e. the request has not been fully transmitted
>> to the server).
>>
>> That is true, but does not mention the requestSentRetryEnabled flag
>>
>> Currently, DefaultHttpRequestRetryHandler Javadoc says:
>>
>> requestSentRetryEnabled true if it's OK to retry requests that have been sent
>>
>> Which is a bit misleading, as it only applies to non-idempotent
>> requests - idempotent requests are always retried.
>>
>> So I think the current Javadoc could do with updating to avoid giving
>> the impression that the flag can be used to prevent idempotent
>> retries.
>>
>>> I am fine with changing the behavior, but in 4.4 branch.
>>
>> That would also need reflecting in the User Guide.
>> And we would need to decide if retries should be separately enabled
>> for idempotent requests.
>>
>> In the meantime, JMeter can create its own retry handler.
>
> Or so I thought ...
>
> Unfortunately it appears that the disconnect only occurs - or perhaps
> is only detected - after the next request has been fully sent.
>
> This means that POST requests that fall foul of this won't be retried
> anyway, and cannot be safely retried.
>
> What would perhaps work for JMeter would be a version of the stale
> connection check that was conditionally applied to a connection.
> For example only after the connection has been idle for a while.
> Unfortunately unconditional stale checking affects performance too
> much.
>
> The only other solution I can see at present is to be able to somehow
> detect the disconnect earlier.
> For example after sending the first line of the request, would it be
> possible to somehow check if the connection has been dropped?
> And could this be done without compromising the performance?
>
> As a work-round for hosts that operate idle timeouts but don't send
> the Keep-Alive response, JMeter could perhaps apply a timeout itself.
> Is that possible?

Sorry, scrap that - I've found the Connection keep alive strategy in
the docs, and tthat works; one can easily provide a keepalive value if
the response does not specify one.

However, it would be useful to be able to detect connection drop
without needing to configure idle timeouts.
And even if the response does specify a timeout, the client and host
clocks may disagree enough to cause the occasional overrun.

>>> 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