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 7B8F21063C for ; Wed, 8 Jan 2014 22:11:05 +0000 (UTC) Received: (qmail 63952 invoked by uid 500); 8 Jan 2014 22:11:05 -0000 Delivered-To: apmail-jmeter-dev-archive@jmeter.apache.org Received: (qmail 63916 invoked by uid 500); 8 Jan 2014 22:11: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 63899 invoked by uid 99); 8 Jan 2014 22:11:04 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 08 Jan 2014 22:11:04 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of philippe.mouawad@gmail.com designates 209.85.223.174 as permitted sender) Received: from [209.85.223.174] (HELO mail-ie0-f174.google.com) (209.85.223.174) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 08 Jan 2014 22:10:58 +0000 Received: by mail-ie0-f174.google.com with SMTP id at1so2746467iec.19 for ; Wed, 08 Jan 2014 14:10:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=lQRQyY5mLm4yL6fNjD2/9QFtPVZx/lf0COpj1MP4wxk=; b=B7hyBeSIuvqaRxx6COg9LANxGpt27PiZoF5ODF3WGYmgcpC8CWV2XyhOUl5CCQS51l xyoRDivBndD8rGPx4Gk+sNzS7ATfEIlyfzCN2e3cvoBmZjQxoq1RJ0XQG8xb3RCyTZna 5FjR1jfTbvvZUO3LyUqhBbFLJFasCC6TubOo+7+N1+TgN/E/MBmbaUE0cg/UC9KNFt9D T072Afp/cJEfdLcCH4GB+zsRTm9hVy+5jn24BLjKyZNWs+BYCiAz8cYtzuvFVLF7hRlv fayYivYffdB0p4cHM1LE/2Of3PTHjzz6c6sz3ziNzR4EyUHElQylpOj6junKVEvczpvt gMMA== MIME-Version: 1.0 X-Received: by 10.50.30.42 with SMTP id p10mr261571igh.5.1389219037404; Wed, 08 Jan 2014 14:10:37 -0800 (PST) Received: by 10.43.64.212 with HTTP; Wed, 8 Jan 2014 14:10:37 -0800 (PST) In-Reply-To: References: Date: Wed, 8 Jan 2014 23:10:37 +0100 Message-ID: Subject: Re: Excalibur pooling [was: Apache Excalibur Logger] From: Philippe Mouawad To: "dev@jmeter.apache.org" Content-Type: multipart/alternative; boundary=047d7bdc9db23e185404ef7cc3a5 X-Virus-Checked: Checked by ClamAV on apache.org --047d7bdc9db23e185404ef7cc3a5 Content-Type: text/plain; charset=ISO-8859-1 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. 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. This time we have an opportunity which we should maybe jump at. My 2cts. Regards Philippe M. On Thu, Aug 23, 2012 at 12:46 AM, sebb wrote: > On 22 August 2012 21:43, Philippe Mouawad > 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. --047d7bdc9db23e185404ef7cc3a5--