jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <>
Subject Re: Bug 56119 - dealing with idle connection timeout and dropped connection
Date Wed, 19 Feb 2014 20:58:54 GMT
On 19 February 2014 18:49, sebb <> wrote:
> It looks as though the problem reported in Bug 56119 was due to the
> server dropping connections that have been idle too long.
> There may also be servers that only allow a connection to be reused a
> certain number of times (this does not seem to have been the case
> here).
> This email is to discuss what JMeter could perhaps do to make it
> easier to test such servers.
> The two existing work-rounds are:
> - disable Keep-Alive
> - enable staleCheck
> Neither is ideal; the first is awkward to use, and staleCheck can
> generate unnecessary additional traffic (which is why it was disabled
> in 2.11).
> I can think of two possible approaches:
> 1) proactively shut connections. This would be easy for servers that
> limit reuse.
> Just count reuses and turn off keep-alive when a specified limit is reached.
> Not so easy for idle timeouts; one cannot retroactively disable keep-alive.
> 2) Deal with the disconnects when they occur.
> The code needs to distinguish which errors are retriable, and may need
> to distinguish at what point the failure occurs. For example, even a
> POST ought to be retriable if JMeter is unable to send any data on the
> connection.
> Also need to consider how one might report retries.
> I think the tester needs to be able to find out if additional requests
> have been made by JMeter.

Further testing against the ASF servers shows that HC 4.2.x does
handle idle timeouts without needing to use the staleCheck option.
This relies on the server sending a header of the form:

Keep-Alive: timeout=5, max=100

In this case, the connection is automatically recreated if necessary
when the next sampler runs.
If the server fails to send the header, then the connection may be
dropped unexpectedly (which is what was happening with Bug 56119).
So another approach might be to allow an optional keep-alive timeout
in case the server does not provide one.

Or we could take the view that there is nothing to fix in JMeter.
The Keep-Alive header is there for a reason, it tells the client when
it is safe to reuse the connectiion.
If the server fails to send it, then it is broken, and so the failed
samples are to be expected.

View raw message