From dev-return-2945-apmail-jmeter-dev-archive=jmeter.apache.org@jmeter.apache.org Thu Jan 9 07:12:13 2014 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 7B5CF106E2 for ; Thu, 9 Jan 2014 07:12:13 +0000 (UTC) Received: (qmail 86680 invoked by uid 500); 9 Jan 2014 07:12:12 -0000 Delivered-To: apmail-jmeter-dev-archive@jmeter.apache.org Received: (qmail 86539 invoked by uid 500); 9 Jan 2014 07:12:04 -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 86531 invoked by uid 99); 9 Jan 2014 07:12:02 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 09 Jan 2014 07:12:02 +0000 X-ASF-Spam-Status: No, hits=1.7 required=5.0 tests=FREEMAIL_ENVFROM_END_DIGIT,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of ra0077@gmail.com designates 209.85.160.49 as permitted sender) Received: from [209.85.160.49] (HELO mail-pb0-f49.google.com) (209.85.160.49) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 09 Jan 2014 07:11:55 +0000 Received: by mail-pb0-f49.google.com with SMTP id jt11so2635914pbb.22 for ; Wed, 08 Jan 2014 23:11:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=4Xx/u4e5L/0Ea0c9nqLsCF4C3LiatL59A1rhu63kyk4=; b=QnbuiYFNMOsxgR9or9hjBvMLUFJDTXbA/4lTQvUfVuZQBunHMt1NoKkmluafwn5j2F 0xFo3sxvlA8JPxaUtWE0bEfn8cRwWibH7Ijrhe5SrFJ/iV8TcOc/879EsI08pwI+6qmd 8qtyYh7FLXNkh8xpMaZElszK1mDNRUVK/YrEsXi/WdvX3/t8azUCtQEHuPGz+FFQR9Eb 6ml71dcQHyPzuV5eSf7wCEmaXLbLR6eW0axj+PhtiD6zfOkSAUnK6U3t7hjETgoX6AVg 4lXA66q7VSRH1p/apFMSFLpB0AIr4/WXL0fX/xMxwnwH8CIX2WitFjDMIivHJrbsiEIg yGAw== X-Received: by 10.67.22.38 with SMTP id hp6mr1828276pad.53.1389251494179; Wed, 08 Jan 2014 23:11:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.70.9.3 with HTTP; Wed, 8 Jan 2014 23:11:13 -0800 (PST) In-Reply-To: References: From: Antonio Gomes Rodrigues Date: Thu, 9 Jan 2014 08:11:13 +0100 Message-ID: Subject: Re: Excalibur pooling [was: Apache Excalibur Logger] To: dev@jmeter.apache.org Content-Type: multipart/alternative; boundary=047d7b5d6122d078e204ef8451d9 X-Virus-Checked: Checked by ClamAV on apache.org --047d7b5d6122d078e204ef8451d9 Content-Type: text/plain; charset=ISO-8859-1 Hi, I am agree with Philippe, it will be great to remove Excalibur and put tomcat pool for 2 reasons : Better performance (see http://www.tomcatexpert.com/blog/2010/03/22/understanding-jdbc-pool-performance-improvementsand http://blog.ippon.fr/2013/03/13/improving-the-performance-of-the-spring-petclinic-sample-application-part-3-of-5/ ) have something which developer know and use Antonio 2014/1/9 sebb > On 8 January 2014 23:07, Philippe Mouawad > wrote: > > On Wednesday, January 8, 2014, sebb wrote: > > > >> On 8 January 2014 22:10, Philippe Mouawad > >> wrote: > >> > Reopening this thread after this bug report: > >> > > >> > - https://issues.apache.org/bugzilla/show_bug.cgi?id=55977 > >> > > >> > > >> > We have 2 options to fix this bug: > >> > > >> > Option 1): > >> > > >> > Upgrade excalibur libraries to 2.1 > >> > > >> > Option 2): > >> > > >> > Switch to a new pooling implementation like Tomcat Pool (or > >> commons-dbcp) . > >> > Tomcat pool is more recent than commons-dbcp and is supposed to have > much > >> > better performances with high number of threads. > >> > > >> > It has all features currently available for excalibur. > >> > >> Not entirely true; Excalibur has quite sophisticated instrumentation > >> (logging). > >> That is how the log was generated and how the problem was found. > >> > >> > As I have said many times in the past, I personnally don't like the > fact > >> we > >> > have some (fortunately very few libraries of retired Apache project > >> > (Excalibur) and would find it great to remove all excalibur related > jars, > >> > but we didn't get a consensus on this. > >> > >> I agree that it is unfortunate that Excalibur has been retired. > >> > >> However just because Commons Pool is newer does not necessarily make > >> it significantly better. > > > > > > I fully agree with you sebb , what i said was based on analysis by tomcat > > team which I tend to trust but we could double check. > > > > I am speaking about tomcat pool vs commons-dbcp > > OK, but the same considerations apply. > > >> Have you compared performances? > > > > > > There are benchmarks between commons dbcp and tomcat-pool I remember I > read > > them, but I can't find them now. > > > > Also tomcat-pool relies on jdk5 concurrent apis. > > http://tomcat.apache.org/tomcat-7.0-doc/jdbc-pool.html > > > > I also made a comparison on a ecommerce website with the 2 pools and it > > had better behaviour. > > But commons-dbcp is a great library also. > > > > I didn't compare perfs of excalibur vs others.My concern is the > deprecation > > state. > > It's not deprecated, just unmaintained. > But if it works, don't fix it. > > > > >> This time we have an opportunity which we should maybe jump at. > >> > >> Changing to an updated version of Excalibur is trivial, and does not > >> affect users who may be relying on its instrumentation. > > > > where is the doc ? > > >> > >> Changing to use Pool instead will require quite a lot of work. > >> We may then find another implementation that is even better and have > >> to go through it all again. > > > > > > commons dbcp is quite stable and tomcat pool is not that new > > I follow the Tomcat lists and there have been some recent fairly basic > bugs reported against it. > So I'm not sure how stable it is yet. > > >> > >> So if we do change, I think we need to do it in such a way that users > >> can plug in whatever pooling implementation they want > > > > > > not sure it is worth, also the aim is to drop excalibur, if we keep it > then > > it is not worth the effort. > > The point is that any pool implementation will have its advantages and > disadvantages. > > Even if we decided to drop Excalibr, I still think it would make sense > to ensure that the pooling code is pluggable. > We don't know what pooling system users will be installing for their > systems. > > > > >> > >> We should anyway do the version update because that is trivial (and > >> easily reversible). > > > > ok > > > >> > >> > > >> > My 2cts. > >> > > >> > Regards > >> > > >> > Philippe M. > >> > > >> > > >> > > >> > > >> > On Thu, Aug 23, 2012 at 12:46 AM, sebb wrote: > >> > > >> >> On 22 August 2012 21:43, Philippe Mouawad < > philippe.mouawad@gmail.com> > >> >> wrote: > >> >> > On Wed, Aug 22, 2012 at 7:21 PM, sebb wrote: > >> >> > > >> >> >> On 22 August 2012 17:52, Milamber wrote: > >> >> >> > On Wed, Aug 22, 2012 at 4:34 PM, Philippe Mouawad < > >> >> >> > philippe.mouawad@gmail.com> wrote: > >> >> > >> >> > >> >> > >> >> >> >> I think we should really remove dependency on Apache Excalibur. > >> >> >> > >> >> >> We still use parts of Excalibur for JDBC pooling. > >> >> >> > >> >> >> I don't see the point of pooling if you are testing JDBC; it then > >> >> >> becomes as much a test of the pool rather than JDBC. > >> >> >> > >> >> > Don't understand this > >> >> > >> >> JMeter threads are intended to represent independent users, so > sharing > >> >> JDBC connections between different threads is equivalent to sharing > >> >> between different users. Does not make sense to me. > >> >> > >> >> But assumijng that there is a use case for sharing a pool between > >> threads: > >> >> If a JDBC performance test shows problems - is it the JDBC database, > >> >> or the pooling implementation? > >> >> What if the pooling implementation is different from the one in the > >> >> application one is simulating? > >> >> > >> >> >> > >> >> >> If we do want to support pooling, it should be selectable. > >> >> >> However I don't know if there is a standard Pooling API, so that > >> might > >> >> >> not be possible. > >> >> >> > >> >> >> Why not use commons-dbcp or tomcat-pool for this ? > >> >> > >> >> They are just specific examples of pools; no different really from > >> >> sticking with Excalibur. > >> >> > >> >> If we truly want to allow users to test pooling, they should be able > >> >> to use any pool they wish, so they can see which one meets their > needs > >> >> best. > >> >> > >> >> But I suspect this will be quite tricky to allow arbitrary pooling > >> >> implementations. > >> >> > >> > > >> > > >> > > >> > -- > >> > Cordialement. > >> > Philippe Mouawad. > >> > > > > > > -- > > Cordialement. > > Philippe Mouawad. > --047d7b5d6122d078e204ef8451d9--