jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Mouawad <philippe.moua...@gmail.com>
Subject Excalibur pooling [was: Apache Excalibur Logger]
Date Wed, 08 Jan 2014 23:07:41 GMT
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

> 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 <sebbaz@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 <sebbaz@gmail.com> wrote:
> >> >
> >> >> On 22 August 2012 17:52, Milamber <milamber@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.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message