You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@jmeter.apache.org by sebb <se...@gmail.com> on 2014/02/19 19:49:32 UTC

Bug 56119 - dealing with idle connection timeout and dropped connection

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.

Re: Bug 56119 - dealing with idle connection timeout and dropped connection

Posted by Philippe Mouawad <ph...@gmail.com>.

On Wed, Feb 19, 2014 at 7:49 PM, sebb <se...@gmail.com> 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() {

    @Override
    public boolean keepAlive(
            final HttpResponse response, final HttpContext context) {
        HttpConnection conn = (HttpConnection)
context.getAttribute(HttpClientContext.HTTP_CONNECTION);
        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:
http://hc.apache.org/httpcomponents-client-4.2.x/tutorial/html/connmgmt.html#d5e652





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



-- 
Cordialement.
Philippe Mouawad.

RE: Bug 56119 - dealing with idle connection timeout and dropped connection

Posted by saurabh gandotra <sa...@hotmail.com>.

In my experience on the client side, the connection stays in TIME_WAIT state and over a period oftime may run out of available FDs unless the ulimit of the user who starts the process is changed.


saurabh gandotra 





> Date: Wed, 19 Feb 2014 21:51:41 +0000
> Subject: Re: Bug 56119 - dealing with idle connection timeout and dropped connection
> From: sebbaz@gmail.com
> To: dev@jmeter.apache.org
> 
> On 19 February 2014 21:03, Philippe Mouawad <ph...@gmail.com> wrote:
> > On Wed, Feb 19, 2014 at 9:58 PM, sebb <se...@gmail.com> wrote:
> >
> >> On 19 February 2014 18:49, sebb <se...@gmail.com> 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.
> >>
> >
> > I think we need to make something at least for servers like Amazon S3 which
> > close connections after number of uses.
> > Did you check to see if this kind of server send a keep alive header ?
> 
> I just tested again with jmeter.a.o.
> It returns headers of the form:
> 
> Keep-Alive: timeout=5, max=100
> Connection: Keep-Alive
> ...
> Keep-Alive: timeout=5, max=99
> Connection: Keep-Alive
> ...
> etc
> ...
> Keep-Alive: timeout=5, max=1
> Connection: Keep-Alive
> ...
> Connection: close
> 
> So the HC connection manager does not need to keep track of the
> remaining re-use count; the server disconnects at the end of the last
> request.
> Nice and simple.
> 
> I assume S3 does the same as jmeter.a.o if it is well-behaved.
> 
> > Anyway on my side I think what has been changed in 2.11 should not be
> > reverted, because for servers correctly configured you don't get these
> > errors, I made 3 campaigns on different servers  with 2.11 and never got
> > this kind of issues.
> 
> Agreed, no need to revert.
> 
> > But maybe we should document it better somewhere.
> 
> Yes, the error and likely cause should be documented.
> Probably easiest to start as a Wiki page.
> 
> >
> >
> > --
> > Cordialement.
> > Philippe Mouawad.