jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Mouawad <>
Subject Re: Bug 56119 - dealing with idle connection timeout and dropped connection
Date Wed, 19 Feb 2014 21:00:01 GMT
On Wed, Feb 19, 2014 at 7:49 PM, 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.
For this method, as per Oleg answers, this seems feasible:

ConnectionReuseStrategy reuseStrategy = new
DefaultConnectionReuseStrategy() {

    public boolean keepAlive(
            final HttpResponse response, final HttpContext context) {
        HttpConnection conn = (HttpConnection)
        long count = conn.getMetrics().getRequestCount();
        if (count >= "make this a parameter or property ?") {
            return false;
        return super.keepAlive(response, context);


Maybe we could also include some info about last use of connection to
disabled it if a certain time has passed.

Another option but which seems to me worst in terms of performances would
be to use this:

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

Philippe Mouawad.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message