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 < [email protected]> wrote: > > > > On Thu, Jan 9, 2014 at 10:04 PM, sebb <[email protected]> wrote: > >> On 9 January 2014 20:52, Philippe Mouawad <[email protected]> >> wrote: >> > On Thu, Jan 9, 2014 at 2:54 PM, sebb <[email protected]> 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 <[email protected]> >> 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 <[email protected]> >> >> > >> >> >> On 8 January 2014 23:07, Philippe Mouawad < >> [email protected]> >> >> >> wrote: >> >> >> > On Wednesday, January 8, 2014, sebb wrote: >> >> >> > >> >> >> >> On 8 January 2014 22:10, Philippe Mouawad < >> >> [email protected]> >> >> >> >> 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 <[email protected]> >> wrote: >> >> >> >> > >> >> >> >> >> On 22 August 2012 21:43, Philippe Mouawad < >> >> >> [email protected]> >> >> >> >> >> wrote: >> >> >> >> >> > On Wed, Aug 22, 2012 at 7:21 PM, sebb <[email protected]> >> wrote: >> >> >> >> >> > >> >> >> >> >> >> On 22 August 2012 17:52, Milamber <[email protected]> >> wrote: >> >> >> >> >> >> > On Wed, Aug 22, 2012 at 4:34 PM, Philippe Mouawad < >> >> >> >> >> >> > [email protected]> 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.
