Mailing-List: contact dev-help@jmeter.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jmeter.apache.org
Received-SPF: pass (athena.apache.org: domain of philippe.mouawad@gmail.com
 designates 209.85.223.176 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAOGo0VYRAXN0vthZXTP7_XLaf4r5Jj1joAp0+bXGWk8O1zSMtQ@mail.gmail.com>
References: 
 <CAOGo0VarzRZH=1DH+TS9xsovErE8p+P8PNdfi9+nw-wXogXuzg@mail.gmail.com>
	<CAOGo0VavR8Lg2jOVYoNBSTOemasi34mN7rJEUxhawcro7x05VQ@mail.gmail.com>
	<CAH9fUpZt17JuOg0aB2KMudxTxWpHpO=bZu3Jv9TaGi_kmcOPLQ@mail.gmail.com>
	<CAOGo0VYRAXN0vthZXTP7_XLaf4r5Jj1joAp0+bXGWk8O1zSMtQ@mail.gmail.com>
Date: Wed, 19 Feb 2014 23:14:23 +0100
Message-ID: 
 <CAH9fUpY4816kHM0zqX+886eH2UNQDskHhEiw7099CgdAMcfB5w@mail.gmail.com>
Subject: Re: Bug 56119 - dealing with idle connection timeout and dropped
 connection
From: Philippe Mouawad <philippe.mouawad@gmail.com>
To: "dev@jmeter.apache.org" <dev@jmeter.apache.org>
Content-Type: multipart/alternative; boundary=bcaec51f966308517f04f2c9b6bd

--bcaec51f966308517f04f2c9b6bd
Content-Type: text/plain; charset=ISO-8859-1

Sebb, what do you mean by jmeter.a.o ?


On Wed, Feb 19, 2014 at 10:51 PM, sebb <sebbaz@gmail.com> wrote:

> On 19 February 2014 21:03, Philippe Mouawad <philippe.mouawad@gmail.com>
> wrote:
> > On Wed, Feb 19, 2014 at 9:58 PM, sebb <sebbaz@gmail.com> wrote:
> >
> >> On 19 February 2014 18:49, sebb <sebbaz@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.
>


-- 
Cordialement.
Philippe Mouawad.

--bcaec51f966308517f04f2c9b6bd--