Also remember that JMeter has a "Use keepalive" option on the HTTP Sampler GUI.
If unchecked, JMeter will send Connection: close (or equivalent) as part of the request. [This does not work reliably for Java HTTP because the connections may be pooled] On 15 February 2014 15:01, Philippe Mouawad <philippe.moua...@gmail.com> wrote: > By default we disable retry but it can be controlled by a parameter. > > Thanks for the info on ConnectionReuseStrategy, it will be a way to handle > these kind of issues. > > Regards > > > On Sat, Feb 15, 2014 at 3:12 PM, Oleg Kalnichevski > <ol...@apache.org<javascript:_e(%7B%7D,'cvml','ol...@apache.org');> >> wrote: > >> On Sat, 2014-02-15 at 14:46 +0100, Philippe Mouawad wrote: >> > Hello Oleg, >> > The problem is that is seems in this particular case, removing this check >> > it leads to 50% error. >> > >> >> What kind of HttpRequestRetryHandler implementation does JMeter 2.11 >> use? Usually with the stale check disabled one should want to retry at >> least some requests automatically. >> >> > I could be explained by a max number of requests per connection setting, >> as >> > per their documentation: >> > - http://aws.amazon.com/articles/1904 >> > >> > "Also, don't overuse a connection. Amazon S3 will accept up to 100 >> requests >> > before it closes a connection (resulting in 'connection reset'). Rather >> > than having this happen, use a connection for 80-90 requests before >> closing >> > and re-opening a new connection." >> > >> > Is there by the way a configuration parameter in HttpClient to limit the >> > number of requests per connection ? >> > >> >> There is no parameter but one can use a custom ConnectionReuseStrategy >> to that effect >> >> --- >> 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 >= 100) { >> return false; >> } >> return super.keepAlive(response, context); >> } >> >> }; >> --- >> >> Hope this helps >> >> Oleg >> >> > Thanks >> > Regards >> > Philippe >> > >> > >> > >> > On Sat, Feb 15, 2014 at 12:49 PM, Oleg Kalnichevski >> > <ol...@apache.org<javascript:_e(%7B%7D,'cvml','ol...@apache.org');> >> >wrote: >> > >> > > On Sat, 2014-02-15 at 11:23 +0100, Philippe Mouawad wrote: >> > > > Hello , >> > > > yes that's it. >> > > > >> > > > regards >> > > > >> > > >> > > Then, I am not sure I understand the problem. The stale connection >> check >> > > is about trading off some performance for fewer i/o errors or visa >> > > versa. >> > > >> > > Oleg >> > > >> > > > On Saturday, February 15, 2014, Oleg Kalnichevski < >> > > o...@ok2consulting.com<javascript:_e(%7B%7D,'cvml','o...@ok2consulting.com');> >> > >> > > > wrote: >> > > > >> > > > > >> > > > > On Fri, 2014-02-14 at 15:42 +0100, Philippe Mouawad wrote: >> > > > > > Hello Oleg, >> > > > > > We set this configuration in JMeter 2.11, we got recently this >> bug >> > > report >> > > > > > related to this change: >> > > > > > https://issues.apache.org/bugzilla/show_bug.cgi?id=56119 >> > > > > > >> > > > > > This issue seems to be faced by another person: >> > > > > > https://twitter.com/cfwhisperer/status/428278488349417472 >> > > > > > >> > > > > > Regards >> > > > > > Philippe >> > > > > > >> > > > > >> > > > > Philippe >> > > > > >> > > > > I am not sure I remember the context. Is it about turning off stale >> > > > > connection checking? >> > > > > >> > > > > Oleg >> > > > > >> > > > > > >> > > > > > On Wed, Dec 11, 2013 at 9:50 AM, Oleg Kalnichevski < >> ol...@apache.org <javascript:_e(%7B%7D,'cvml','ol...@apache.org');> >> > > <javascript:;>> >> > > > > wrote: >> > > > > > >> > > > > > > On Tue, 2013-12-10 at 21:38 +0100, Philippe Mouawad wrote: >> > > > > > > > Hello Oleg, >> > > > > > > > Thanks for answer. >> > > > > > > > Wouldn't it be interesting to add some threshold or delay >> between >> > > > > each >> > > > > > > > check instead of doing check on each request ? >> > > > > > > > >> > > > > > > > Regards >> > > > > > > > Philippe >> > > > > > > > >> > > > > > > >> > > > > > > Philippe >> > > > > > > >> > > > > > > I am not sure it is worth the trouble. In most circumstances >> the >> > > stale >> > > > > > > connection check should be turned off anyway. >> > > > > > > >> > > > > > > I think it just needs to be better documented. >> > > > > > > >> > > > > > > Oleg >> > > > > > > >> > > > > > > > >> > > > > > > > On Mon, Dec 9, 2013 at 11:59 AM, Oleg Kalnichevski < >> > > ol...@apache.org <javascript:_e(%7B%7D,'cvml','ol...@apache.org');> >> <javascript:;> >> > > > > > >> > > > > > > wrote: >> > > > > > > > >> > > > > > > > > On Sun, 2013-12-08 at 21:32 +0100, Philippe Mouawad wrote: >> > > > > > > > > > Hello, >> > > > > > > > > > Profiling JMeter, I noticed an important number of >> > > > > > > SocketTimeoutException >> > > > > > > > > > being triggered without any impact on response status. >> > > > > > > > > > >> > > > > > > > > > I investigated it a bit deeper and find out it affected >> only >> > > > > > > HttpClient >> > > > > > > > > > implementations. >> > > > > > > > > > Looking a bit deeper, it is due to connection stale check >> > > which >> > > > > is >> > > > > > > > > enabled >> > > > > > > > > > by default. >> > > > > > > > > > This check sets a timeout to 1ms , see : >> > > > > > > > > > - >> org.apache.http.impl.io.SocketInputBuffer#isDataAvailable >> > > > > > > > > > - >> org.apache.http.impl.AbstractHttpClientConnection#isStale >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > Is this the only and best way to check for stale >> connection ? >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > Regards >> > > > > > > > > > Philippe >> > > > > > > > > >> > > > > > > > > Philippe >> > > > > > > > > >> > > > > > > > > I personally do not know of a different (better) way of >> > > finding out >> > > > > > > > > whether or not a blocking connection is still valid. >> > > > > > > > > >> > > > > > > > > Oleg >> > > > > > > > > >> > > > > > > > > >> > > > > > > > > >> > > > > >> --------------------------------------------------------------------- >> > > > > > > > > To unsubscribe, e-mail: >> > > httpclient-users-unsubscr...@hc.apache.org<javascript:_e(%7B%7D,'cvml','httpclient-users-unsubscr...@hc.apache.org');> >> <javascript:;> >> > > > > > > > > For additional commands, e-mail: >> > > > > httpclient-users-h...@hc.apache.org<javascript:_e(%7B%7D,'cvml','httpclient-users-h...@hc.apache.org');><javascript:;> >> > > > > > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > --------------------------------------------------------------------- >> > > > > > > To unsubscribe, e-mail: >> httpclient-users-unsubscr...@hc.apache.org<javascript:_e(%7B%7D,'cvml','httpclient-users-unsubscr...@hc.apache.org');> >> > > <javascript:;> >> > > > > > > For additional commands, e-mail: >> > > httpclient-users-h...@hc.apache.org<javascript:_e(%7B%7D,'cvml','httpclient-users-h...@hc.apache.org');> >> <javascript:;> >> > > > > > > >> > > > > > > >> > > > > > >> > > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> --------------------------------------------------------------------- >> > > > > To unsubscribe, e-mail: >> > > > > httpclient-users-unsubscr...@hc.apache.org<javascript:_e(%7B%7D,'cvml','httpclient-users-unsubscr...@hc.apache.org');> >> > > <javascript:;> >> > > > > For additional commands, e-mail: >> httpclient-users-h...@hc.apache.org<javascript:_e(%7B%7D,'cvml','httpclient-users-h...@hc.apache.org');> >> > > <javascript:;> >> > > > > >> > > > > >> > > > >> > > >> > > >> > > >> > >> > >> >> >> > > > -- > Cordialement. > Philippe Mouawad. > > > > > -- > Cordialement. > Philippe Mouawad. --------------------------------------------------------------------- To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org
