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: [email protected] > To: [email protected] > > On 19 February 2014 21:03, Philippe Mouawad <[email protected]> > wrote: > > On Wed, Feb 19, 2014 at 9:58 PM, sebb <[email protected]> wrote: > > > >> On 19 February 2014 18:49, sebb <[email protected]> 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.
