Return-Path: X-Original-To: apmail-jmeter-dev-archive@minotaur.apache.org Delivered-To: apmail-jmeter-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id A28281086C for ; Sat, 15 Feb 2014 15:39:49 +0000 (UTC) Received: (qmail 51329 invoked by uid 500); 15 Feb 2014 15:39:47 -0000 Delivered-To: apmail-jmeter-dev-archive@jmeter.apache.org Received: (qmail 51275 invoked by uid 500); 15 Feb 2014 15:39:46 -0000 Mailing-List: contact dev-help@jmeter.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@jmeter.apache.org Delivered-To: mailing list dev@jmeter.apache.org Received: (qmail 51258 invoked by uid 99); 15 Feb 2014 15:39:44 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 15 Feb 2014 15:39:44 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy includes SPF record at spf.trusted-forwarder.org) Received: from [5.148.180.21] (HELO kalnich2.nine.ch) (5.148.180.21) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 15 Feb 2014 15:39:37 +0000 Received: from [10.80.39.105] (unknown [91.137.20.132]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by kalnich2.nine.ch (Postfix) with ESMTPSA id AF2CE1601DE; Sat, 15 Feb 2014 15:39:16 +0000 (UTC) Message-ID: <1392478754.27726.15.camel@ubuntu> Subject: Re: HttpClient 4.2.6 : ManagedClientConnectionImpl way of checking stale connection and Performances From: Oleg Kalnichevski To: HttpClient User Discussion Cc: "dev@jmeter.apache.org" Date: Sat, 15 Feb 2014 16:39:14 +0100 In-Reply-To: References: <1386586783.24937.1.camel@ubuntu> <1386751854.8917.6.camel@ubuntu> <1392457292.20446.8.camel@ubuntu> <1392464960.25744.2.camel@ubuntu> <1392473526.27726.10.camel@ubuntu> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.8.4-0ubuntu1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org On Sat, 2014-02-15 at 16:01 +0100, Philippe Mouawad wrote: > By default we disable retry but it can be controlled by a parameter. > I have say you may want to have a retry handler enabled by default if the stale check is off. At the very least you may want to retry idempotent requests or some specific type of exceptions (like 'server failed to respond'). Oleg > 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 > > > 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 > > >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 < > > > > oleg@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 < > > olegk@apache.org > > > > > > > > > > > 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 < > > > > olegk@apache.org > > > > > > > > > > > > > > > > > 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-unsubscribe@hc.apache.org > > > > > > > > > > > > For additional commands, e-mail: > > > > > > httpclient-users-help@hc.apache.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > To unsubscribe, e-mail: > > httpclient-users-unsubscribe@hc.apache.org > > > > > > > > > > > > For additional commands, e-mail: > > > > httpclient-users-help@hc.apache.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org > > > > > > > > > > For additional commands, e-mail: > > httpclient-users-help@hc.apache.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > Cordialement. > Philippe Mouawad. > > > >