On 8 January 2014 23:07, Philippe Mouawad <philippe.moua...@gmail.com> wrote: > On Wednesday, January 8, 2014, sebb wrote: > >> On 8 January 2014 22:10, Philippe Mouawad <philippe.moua...@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 <seb...@gmail.com> wrote: >> > >> >> On 22 August 2012 21:43, Philippe Mouawad <philippe.moua...@gmail.com> >> >> wrote: >> >> > On Wed, Aug 22, 2012 at 7:21 PM, sebb <seb...@gmail.com> wrote: >> >> > >> >> >> On 22 August 2012 17:52, Milamber <milam...@apache.org> wrote: >> >> >> > On Wed, Aug 22, 2012 at 4:34 PM, Philippe Mouawad < >> >> >> > philippe.moua...@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.
