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 saurabh_gandotra@hotmail.com
 designates 65.54.190.227 as permitted sender)
Message-ID: <BAY169-W126BE50F515BF62D2FD3FEFEA9B0@phx.gbl>
Content-Type: multipart/alternative;
	boundary="_01a99e05-b97f-4fe3-bd82-d08f6d4ecaa8_"
From: saurabh gandotra <saurabh_gandotra@hotmail.com>
To: "dev@jmeter.apache.org" <dev@jmeter.apache.org>
Subject: RE: Bug 56119 - dealing with idle connection timeout and dropped
 connection
Date: Wed, 19 Feb 2014 14:13:05 -0800
Importance: Normal
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>
MIME-Version: 1.0

--_01a99e05-b97f-4fe3-bd82-d08f6d4ecaa8_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

In my experience on the client side=2C the connection stays in TIME_WAIT st=
ate 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=20


> Date: Wed=2C 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
>=20
> On 19 February 2014 21:03=2C Philippe Mouawad <philippe.mouawad@gmail.com=
> wrote:
> > On Wed=2C Feb 19=2C 2014 at 9:58 PM=2C sebb <sebbaz@gmail.com> wrote:
> >
> >> On 19 February 2014 18:49=2C 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=3B the first is awkward to use=2C and staleCheck ca=
n
> >> > generate unnecessary additional traffic (which is why it was disable=
d
> >> > 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=3B one cannot retroactively disable
> >> keep-alive.
> >> >
> >> > 2) Deal with the disconnects when they occur.
> >> > The code needs to distinguish which errors are retriable=2C and may =
need
> >> > to distinguish at what point the failure occurs. For example=2C even=
 a
> >> > POST ought to be retriable if JMeter is unable to send any data on t=
he
> >> > connection.
> >> >
> >> > Also need to consider how one might report retries.
> >> > I think the tester needs to be able to find out if additional reques=
ts
> >> > 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=3D5=2C max=3D100
> >>
> >> In this case=2C the connection is automatically recreated if necessary
> >> when the next sampler runs.
> >> If the server fails to send the header=2C 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=2C it tells the client whe=
n
> >> it is safe to reuse the connectiion.
> >> If the server fails to send it=2C then it is broken=2C and so the fail=
ed
> >> samples are to be expected.
> >>
> >
> > I think we need to make something at least for servers like Amazon S3 w=
hich
> > close connections after number of uses.
> > Did you check to see if this kind of server send a keep alive header ?
>=20
> I just tested again with jmeter.a.o.
> It returns headers of the form:
>=20
> Keep-Alive: timeout=3D5=2C max=3D100
> Connection: Keep-Alive
> ...
> Keep-Alive: timeout=3D5=2C max=3D99
> Connection: Keep-Alive
> ...
> etc
> ...
> Keep-Alive: timeout=3D5=2C max=3D1
> Connection: Keep-Alive
> ...
> Connection: close
>=20
> So the HC connection manager does not need to keep track of the
> remaining re-use count=3B the server disconnects at the end of the last
> request.
> Nice and simple.
>=20
> I assume S3 does the same as jmeter.a.o if it is well-behaved.
>=20
> > Anyway on my side I think what has been changed in 2.11 should not be
> > reverted=2C because for servers correctly configured you don't get thes=
e
> > errors=2C I made 3 campaigns on different servers  with 2.11 and never =
got
> > this kind of issues.
>=20
> Agreed=2C no need to revert.
>=20
> > But maybe we should document it better somewhere.
>=20
> Yes=2C the error and likely cause should be documented.
> Probably easiest to start as a Wiki page.
>=20
> >
> >
> > --
> > Cordialement.
> > Philippe Mouawad.
 		 	   		  =

--_01a99e05-b97f-4fe3-bd82-d08f6d4ecaa8_--