You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jmeter.apache.org by sebb <se...@gmail.com> on 2012/08/23 00:46:04 UTC
Excalibur pooling [was: Apache Excalibur Logger]
On 22 August 2012 21:43, Philippe Mouawad <ph...@gmail.com> wrote:
> On Wed, Aug 22, 2012 at 7:21 PM, sebb <se...@gmail.com> wrote:
>
>> On 22 August 2012 17:52, Milamber <mi...@apache.org> wrote:
>> > On Wed, Aug 22, 2012 at 4:34 PM, Philippe Mouawad <
>> > philippe.mouawad@gmail.com> wrote:
<snip/>
>> >> 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.
Re: Excalibur pooling [was: Apache Excalibur Logger]
Posted by Philippe Mouawad <ph...@gmail.com>.
Hello,
For follow up, fixed within bug 58786:
https://bz.apache.org/bugzilla/show_bug.cgi?id=58786
Regards
On Thu, Jan 9, 2014 at 10:22 PM, Philippe Mouawad <
philippe.mouawad@gmail.com> wrote:
>
>
>
> On Thu, Jan 9, 2014 at 10:04 PM, sebb <se...@gmail.com> wrote:
>
>> On 9 January 2014 20:52, Philippe Mouawad <ph...@gmail.com>
>> wrote:
>> > On Thu, Jan 9, 2014 at 2:54 PM, sebb <se...@gmail.com> wrote:
>> >
>> >> No-one seems to have addressed one of the main issues: why should
>> >> JMeter use JDBC pooling at all?
>> >>
>> >
>> > It already exists sebb, so it means it is useful.
>> >
>> >
>> >> JMeter threads generally represent independent users.
>> >> Would such users share a JDBC pool?
>> >>
>> >
>> > Well the pool can be useful to simulate the behaviour of an application
>> > server.
>> > Users would want to load test to determine the minimum sizing of the
>> pool
>> > to handle a set of SQL queries that are executed simulatenously.
>>
>> In which case, the user will surely want to be able to try different
>> pool implementations.
>>
>
> No I think he will want to configure his pool in a similar way as his J2EE
> Container (Tomcat, Weblogic, JBoss, Websphere) .
> But you won't be able to have the exact pool implementation used by
> commercial containers. Although configuration parameters are very similar
> between implementations.
>
> I think having a pool configured in a similar way as Container would be
> enough
>
>
>> >
>> >>
>> >> Isn't any pooling likely to be done by the server anyway?
>> >>
>> >
>> > Yes probably, but maybe user want's to isolate test on a set of
>> queries, do
>> > optimizations on DB or SQL query and see effect.
>>
>> In which case, having pooling as well is going to complicate the testing.
>> But at least the JMeter pooling can be disabled.
>>
>
> I don't understand your argument. User will want to see with a pool
> configured in a certain way how his database reacts.
>
>
>> It makes little sense to have *any* pooling in JMeter.
>>
>
>
>
>> It makes no sense at all to have a fixed pooling implementation in JMeter.
>> But given that we have got it and it works and some people use it, it
>> should stay.
>>
>> If there really is a use-case for having (different) pooling, then the
>> pooling implementation should be selectable.
>>
>
> Why not if your really want it ?
>
>
>> >
>> >>
>> >> If pooling is supposed to be done by the client(s) - i.e. JMeter -
>> >> then surely the implementation should be configurable?
>> >>
>> >
>> >
>> >
>> >> Otherwise JMeter is making the choice for the user.
>> >>
>> >> On 9 January 2014 07:11, Antonio Gomes Rodrigues <ra...@gmail.com>
>> wrote:
>> >> > 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 <se...@gmail.com>
>> >> >
>> >> >> On 8 January 2014 23:07, Philippe Mouawad <
>> philippe.mouawad@gmail.com>
>> >> >> wrote:
>> >> >> > On Wednesday, January 8, 2014, sebb wrote:
>> >> >> >
>> >> >> >> On 8 January 2014 22:10, Philippe Mouawad <
>> >> philippe.mouawad@gmail.com>
>> >> >> >> 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 <se...@gmail.com>
>> wrote:
>> >> >> >> >
>> >> >> >> >> On 22 August 2012 21:43, Philippe Mouawad <
>> >> >> philippe.mouawad@gmail.com>
>> >> >> >> >> wrote:
>> >> >> >> >> > On Wed, Aug 22, 2012 at 7:21 PM, sebb <se...@gmail.com>
>> wrote:
>> >> >> >> >> >
>> >> >> >> >> >> On 22 August 2012 17:52, Milamber <mi...@apache.org>
>> wrote:
>> >> >> >> >> >> > On Wed, Aug 22, 2012 at 4:34 PM, Philippe Mouawad <
>> >> >> >> >> >> > philippe.mouawad@gmail.com> wrote:
>> >> >> >> >>
>> >> >> >> >> <snip/>
>> >> >> >> >>
>> >> >> >> >> >> >> 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.
>> >> >>
>> >>
>> >
>> >
>> >
>> > --
>> > Cordialement.
>> > Philippe Mouawad.
>>
>
>
>
> --
> Cordialement.
> Philippe Mouawad.
>
>
>
--
Cordialement.
Philippe Mouawad.
Re: Excalibur pooling [was: Apache Excalibur Logger]
Posted by Philippe Mouawad <ph...@gmail.com>.
On Thu, Jan 9, 2014 at 10:04 PM, sebb <se...@gmail.com> wrote:
> On 9 January 2014 20:52, Philippe Mouawad <ph...@gmail.com>
> wrote:
> > On Thu, Jan 9, 2014 at 2:54 PM, sebb <se...@gmail.com> wrote:
> >
> >> No-one seems to have addressed one of the main issues: why should
> >> JMeter use JDBC pooling at all?
> >>
> >
> > It already exists sebb, so it means it is useful.
> >
> >
> >> JMeter threads generally represent independent users.
> >> Would such users share a JDBC pool?
> >>
> >
> > Well the pool can be useful to simulate the behaviour of an application
> > server.
> > Users would want to load test to determine the minimum sizing of the pool
> > to handle a set of SQL queries that are executed simulatenously.
>
> In which case, the user will surely want to be able to try different
> pool implementations.
>
No I think he will want to configure his pool in a similar way as his J2EE
Container (Tomcat, Weblogic, JBoss, Websphere) .
But you won't be able to have the exact pool implementation used by
commercial containers. Although configuration parameters are very similar
between implementations.
I think having a pool configured in a similar way as Container would be
enough
> >
> >>
> >> Isn't any pooling likely to be done by the server anyway?
> >>
> >
> > Yes probably, but maybe user want's to isolate test on a set of queries,
> do
> > optimizations on DB or SQL query and see effect.
>
> In which case, having pooling as well is going to complicate the testing.
> But at least the JMeter pooling can be disabled.
>
I don't understand your argument. User will want to see with a pool
configured in a certain way how his database reacts.
> It makes little sense to have *any* pooling in JMeter.
>
> It makes no sense at all to have a fixed pooling implementation in JMeter.
> But given that we have got it and it works and some people use it, it
> should stay.
>
> If there really is a use-case for having (different) pooling, then the
> pooling implementation should be selectable.
>
Why not if your really want it ?
>
> >
> >>
> >> If pooling is supposed to be done by the client(s) - i.e. JMeter -
> >> then surely the implementation should be configurable?
> >>
> >
> >
> >
> >> Otherwise JMeter is making the choice for the user.
> >>
> >> On 9 January 2014 07:11, Antonio Gomes Rodrigues <ra...@gmail.com>
> wrote:
> >> > 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 <se...@gmail.com>
> >> >
> >> >> On 8 January 2014 23:07, Philippe Mouawad <
> philippe.mouawad@gmail.com>
> >> >> wrote:
> >> >> > On Wednesday, January 8, 2014, sebb wrote:
> >> >> >
> >> >> >> On 8 January 2014 22:10, Philippe Mouawad <
> >> philippe.mouawad@gmail.com>
> >> >> >> 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 <se...@gmail.com>
> wrote:
> >> >> >> >
> >> >> >> >> On 22 August 2012 21:43, Philippe Mouawad <
> >> >> philippe.mouawad@gmail.com>
> >> >> >> >> wrote:
> >> >> >> >> > On Wed, Aug 22, 2012 at 7:21 PM, sebb <se...@gmail.com>
> wrote:
> >> >> >> >> >
> >> >> >> >> >> On 22 August 2012 17:52, Milamber <mi...@apache.org>
> wrote:
> >> >> >> >> >> > On Wed, Aug 22, 2012 at 4:34 PM, Philippe Mouawad <
> >> >> >> >> >> > philippe.mouawad@gmail.com> wrote:
> >> >> >> >>
> >> >> >> >> <snip/>
> >> >> >> >>
> >> >> >> >> >> >> 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.
> >> >>
> >>
> >
> >
> >
> > --
> > Cordialement.
> > Philippe Mouawad.
>
--
Cordialement.
Philippe Mouawad.
Re: Excalibur pooling [was: Apache Excalibur Logger]
Posted by sebb <se...@gmail.com>.
On 9 January 2014 20:52, Philippe Mouawad <ph...@gmail.com> wrote:
> On Thu, Jan 9, 2014 at 2:54 PM, sebb <se...@gmail.com> wrote:
>
>> No-one seems to have addressed one of the main issues: why should
>> JMeter use JDBC pooling at all?
>>
>
> It already exists sebb, so it means it is useful.
>
>
>> JMeter threads generally represent independent users.
>> Would such users share a JDBC pool?
>>
>
> Well the pool can be useful to simulate the behaviour of an application
> server.
> Users would want to load test to determine the minimum sizing of the pool
> to handle a set of SQL queries that are executed simulatenously.
In which case, the user will surely want to be able to try different
pool implementations.
>
>>
>> Isn't any pooling likely to be done by the server anyway?
>>
>
> Yes probably, but maybe user want's to isolate test on a set of queries, do
> optimizations on DB or SQL query and see effect.
In which case, having pooling as well is going to complicate the testing.
But at least the JMeter pooling can be disabled.
It makes little sense to have *any* pooling in JMeter.
It makes no sense at all to have a fixed pooling implementation in JMeter.
But given that we have got it and it works and some people use it, it
should stay.
If there really is a use-case for having (different) pooling, then the
pooling implementation should be selectable.
>
>>
>> If pooling is supposed to be done by the client(s) - i.e. JMeter -
>> then surely the implementation should be configurable?
>>
>
>
>
>> Otherwise JMeter is making the choice for the user.
>>
>> On 9 January 2014 07:11, Antonio Gomes Rodrigues <ra...@gmail.com> wrote:
>> > 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 <se...@gmail.com>
>> >
>> >> On 8 January 2014 23:07, Philippe Mouawad <ph...@gmail.com>
>> >> wrote:
>> >> > On Wednesday, January 8, 2014, sebb wrote:
>> >> >
>> >> >> On 8 January 2014 22:10, Philippe Mouawad <
>> philippe.mouawad@gmail.com>
>> >> >> 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 <se...@gmail.com> wrote:
>> >> >> >
>> >> >> >> On 22 August 2012 21:43, Philippe Mouawad <
>> >> philippe.mouawad@gmail.com>
>> >> >> >> wrote:
>> >> >> >> > On Wed, Aug 22, 2012 at 7:21 PM, sebb <se...@gmail.com> wrote:
>> >> >> >> >
>> >> >> >> >> On 22 August 2012 17:52, Milamber <mi...@apache.org> wrote:
>> >> >> >> >> > On Wed, Aug 22, 2012 at 4:34 PM, Philippe Mouawad <
>> >> >> >> >> > philippe.mouawad@gmail.com> wrote:
>> >> >> >>
>> >> >> >> <snip/>
>> >> >> >>
>> >> >> >> >> >> 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.
>> >>
>>
>
>
>
> --
> Cordialement.
> Philippe Mouawad.
Re: Excalibur pooling [was: Apache Excalibur Logger]
Posted by Philippe Mouawad <ph...@gmail.com>.
On Thu, Jan 9, 2014 at 2:54 PM, sebb <se...@gmail.com> wrote:
> No-one seems to have addressed one of the main issues: why should
> JMeter use JDBC pooling at all?
>
It already exists sebb, so it means it is useful.
> JMeter threads generally represent independent users.
> Would such users share a JDBC pool?
>
Well the pool can be useful to simulate the behaviour of an application
server.
Users would want to load test to determine the minimum sizing of the pool
to handle a set of SQL queries that are executed simulatenously.
>
> Isn't any pooling likely to be done by the server anyway?
>
Yes probably, but maybe user want's to isolate test on a set of queries, do
optimizations on DB or SQL query and see effect.
>
> If pooling is supposed to be done by the client(s) - i.e. JMeter -
> then surely the implementation should be configurable?
>
> Otherwise JMeter is making the choice for the user.
>
> On 9 January 2014 07:11, Antonio Gomes Rodrigues <ra...@gmail.com> wrote:
> > 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 <se...@gmail.com>
> >
> >> On 8 January 2014 23:07, Philippe Mouawad <ph...@gmail.com>
> >> wrote:
> >> > On Wednesday, January 8, 2014, sebb wrote:
> >> >
> >> >> On 8 January 2014 22:10, Philippe Mouawad <
> philippe.mouawad@gmail.com>
> >> >> 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 <se...@gmail.com> wrote:
> >> >> >
> >> >> >> On 22 August 2012 21:43, Philippe Mouawad <
> >> philippe.mouawad@gmail.com>
> >> >> >> wrote:
> >> >> >> > On Wed, Aug 22, 2012 at 7:21 PM, sebb <se...@gmail.com> wrote:
> >> >> >> >
> >> >> >> >> On 22 August 2012 17:52, Milamber <mi...@apache.org> wrote:
> >> >> >> >> > On Wed, Aug 22, 2012 at 4:34 PM, Philippe Mouawad <
> >> >> >> >> > philippe.mouawad@gmail.com> wrote:
> >> >> >>
> >> >> >> <snip/>
> >> >> >>
> >> >> >> >> >> 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.
> >>
>
--
Cordialement.
Philippe Mouawad.
Re: Excalibur pooling [was: Apache Excalibur Logger]
Posted by sebb <se...@gmail.com>.
No-one seems to have addressed one of the main issues: why should
JMeter use JDBC pooling at all?
JMeter threads generally represent independent users.
Would such users share a JDBC pool?
Isn't any pooling likely to be done by the server anyway?
If pooling is supposed to be done by the client(s) - i.e. JMeter -
then surely the implementation should be configurable?
Otherwise JMeter is making the choice for the user.
On 9 January 2014 07:11, Antonio Gomes Rodrigues <ra...@gmail.com> wrote:
> 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 <se...@gmail.com>
>
>> On 8 January 2014 23:07, Philippe Mouawad <ph...@gmail.com>
>> wrote:
>> > On Wednesday, January 8, 2014, sebb wrote:
>> >
>> >> On 8 January 2014 22:10, Philippe Mouawad <ph...@gmail.com>
>> >> 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 <se...@gmail.com> wrote:
>> >> >
>> >> >> On 22 August 2012 21:43, Philippe Mouawad <
>> philippe.mouawad@gmail.com>
>> >> >> wrote:
>> >> >> > On Wed, Aug 22, 2012 at 7:21 PM, sebb <se...@gmail.com> wrote:
>> >> >> >
>> >> >> >> On 22 August 2012 17:52, Milamber <mi...@apache.org> wrote:
>> >> >> >> > On Wed, Aug 22, 2012 at 4:34 PM, Philippe Mouawad <
>> >> >> >> > philippe.mouawad@gmail.com> wrote:
>> >> >>
>> >> >> <snip/>
>> >> >>
>> >> >> >> >> 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.
>>
Re: Excalibur pooling [was: Apache Excalibur Logger]
Posted by Antonio Gomes Rodrigues <ra...@gmail.com>.
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 <se...@gmail.com>
> On 8 January 2014 23:07, Philippe Mouawad <ph...@gmail.com>
> wrote:
> > On Wednesday, January 8, 2014, sebb wrote:
> >
> >> On 8 January 2014 22:10, Philippe Mouawad <ph...@gmail.com>
> >> 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 <se...@gmail.com> wrote:
> >> >
> >> >> On 22 August 2012 21:43, Philippe Mouawad <
> philippe.mouawad@gmail.com>
> >> >> wrote:
> >> >> > On Wed, Aug 22, 2012 at 7:21 PM, sebb <se...@gmail.com> wrote:
> >> >> >
> >> >> >> On 22 August 2012 17:52, Milamber <mi...@apache.org> wrote:
> >> >> >> > On Wed, Aug 22, 2012 at 4:34 PM, Philippe Mouawad <
> >> >> >> > philippe.mouawad@gmail.com> wrote:
> >> >>
> >> >> <snip/>
> >> >>
> >> >> >> >> 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.
>
Re: Excalibur pooling [was: Apache Excalibur Logger]
Posted by sebb <se...@gmail.com>.
On 8 January 2014 23:07, Philippe Mouawad <ph...@gmail.com> wrote:
> On Wednesday, January 8, 2014, sebb wrote:
>
>> On 8 January 2014 22:10, Philippe Mouawad <ph...@gmail.com>
>> 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 <se...@gmail.com> wrote:
>> >
>> >> On 22 August 2012 21:43, Philippe Mouawad <ph...@gmail.com>
>> >> wrote:
>> >> > On Wed, Aug 22, 2012 at 7:21 PM, sebb <se...@gmail.com> wrote:
>> >> >
>> >> >> On 22 August 2012 17:52, Milamber <mi...@apache.org> wrote:
>> >> >> > On Wed, Aug 22, 2012 at 4:34 PM, Philippe Mouawad <
>> >> >> > philippe.mouawad@gmail.com> wrote:
>> >>
>> >> <snip/>
>> >>
>> >> >> >> 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.
Excalibur pooling [was: Apache Excalibur Logger]
Posted by Philippe Mouawad <ph...@gmail.com>.
On Wednesday, January 8, 2014, sebb wrote:
> On 8 January 2014 22:10, Philippe Mouawad <ph...@gmail.com>
> 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
> 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.
> 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
>
> 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.
>
> 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 <se...@gmail.com> wrote:
> >
> >> On 22 August 2012 21:43, Philippe Mouawad <ph...@gmail.com>
> >> wrote:
> >> > On Wed, Aug 22, 2012 at 7:21 PM, sebb <se...@gmail.com> wrote:
> >> >
> >> >> On 22 August 2012 17:52, Milamber <mi...@apache.org> wrote:
> >> >> > On Wed, Aug 22, 2012 at 4:34 PM, Philippe Mouawad <
> >> >> > philippe.mouawad@gmail.com> wrote:
> >>
> >> <snip/>
> >>
> >> >> >> 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.
Re: Excalibur pooling [was: Apache Excalibur Logger]
Posted by sebb <se...@gmail.com>.
On 8 January 2014 22:10, Philippe Mouawad <ph...@gmail.com> 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.
Have you compared performances?
> 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.
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.
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
We should anyway do the version update because that is trivial (and
easily reversible).
>
> My 2cts.
>
> Regards
>
> Philippe M.
>
>
>
>
> On Thu, Aug 23, 2012 at 12:46 AM, sebb <se...@gmail.com> wrote:
>
>> On 22 August 2012 21:43, Philippe Mouawad <ph...@gmail.com>
>> wrote:
>> > On Wed, Aug 22, 2012 at 7:21 PM, sebb <se...@gmail.com> wrote:
>> >
>> >> On 22 August 2012 17:52, Milamber <mi...@apache.org> wrote:
>> >> > On Wed, Aug 22, 2012 at 4:34 PM, Philippe Mouawad <
>> >> > philippe.mouawad@gmail.com> wrote:
>>
>> <snip/>
>>
>> >> >> 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.
Re: Excalibur pooling [was: Apache Excalibur Logger]
Posted by Philippe Mouawad <ph...@gmail.com>.
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 <se...@gmail.com> wrote:
> On 22 August 2012 21:43, Philippe Mouawad <ph...@gmail.com>
> wrote:
> > On Wed, Aug 22, 2012 at 7:21 PM, sebb <se...@gmail.com> wrote:
> >
> >> On 22 August 2012 17:52, Milamber <mi...@apache.org> wrote:
> >> > On Wed, Aug 22, 2012 at 4:34 PM, Philippe Mouawad <
> >> > philippe.mouawad@gmail.com> wrote:
>
> <snip/>
>
> >> >> 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.