On 4 January 2016 at 18:28, Philippe Mouawad <philippe.moua...@gmail.com> wrote: > On Mon, Jan 4, 2016 at 4:21 PM, sebb <seb...@gmail.com> wrote: > >> On 2 January 2016 at 15:38, Felix Schumacher >> <felix.schumac...@internetallee.de> wrote: >> > Hi all, >> > >> > in our documentation there is one section about the sizing of the pool, >> > which I like to discuss: >> > >> > "If you really want to use shared pooling (why?), then set the max count >> to >> > the same as the number of threads to ensure threads don't wait on each >> > other." >> > >> > First: I think pooling is a valid option even for user-centric scenarios. >> > Think about simulating the sql requests of an application server. In >> such a >> > case a pool would have been used, so why not when simulating it? >> > >> > So for this part, I question the part "...(why?)..." and the "really" in >> > front of it. >> >> The problem is that JMeter is then mainly testing the pool >> implementation rather than the server. >> > > Not from Felix notes on bug. But read below. > >> Since the pool implementation cannot at present be replaced, that does >> not seem to be a useful approach. >> > > I implemented 3 classes corresponding to 3 major pools (DBCP2, Tomcat JDBC, > HikariCP) >
However, there are lots of other pools. > >> >> > Second: When a pool is used (at least the dbcp2 pool) the connections >> seem >> > to be stored in a stack like construct. So in a uncontended load >> situation >> > the pool will use only a fraction of the configured size and in a >> contended >> > situation with really many threads it will probably overload the db. >> >> That suggests that pooling should not be used by JMeter... >> > > I don't share your opinion. In the context of the dbcp2 pool, it's just an observation, not an opinion. > I really think proposing the pool is useful. What is the use case? >> >> > So all in all I would rather change the sentence to something like "If >> you >> > want to use shared pooling, then set the max count to something >> sensible". >> >> I think we need to document why pooling is not in general a good idea >> for JMeter tests. >> > Ok > >> >> However I would prefer to drop pooling support entirely unless the >> pool implementation can be provided by the user. >> > > I don't share your opinion for many reasons: > > - First there is no much remaining job to make it possible to test other > pool: > - Propose a Factory > - We could even embed the 2 others that were tested > - We improved as we dropped a deprected library, why drop now which > means more work for less feature However it's not possible for the user to drop in a brand new pool without writing a factory class. Unlike (say) with JDBC or JSR-223, where the user can use any implementation which has the bindings. > - From users comments I tend to think this feature is useful and users > are expecting it Examples of such comments? > - Finally , we spent Felix and I some time working on this on our > personal time, dropping it is just a waste of our time and work, which is > discouraging for me to be frank with you I have had a look at the dev list archives and the last time the issue was discussed (August 2012) I made it clear that it only made sense to include pooling if the implementation was configurable. And when I raised the issue on the user list as I recall there was no feedback saying that the feature was needed. It's unfortunate that I was away over Xmas otherwise I would have raised my concerns a bit earlier. However I don't see any recent discussion on pooling, so I'm not sure how I could have raised the issue before work was started. == I still think that JBDC pooling is unnecessary. I have yet to see a good use case. Also if there is a use case, that it only makes sense to provide pooling if the implementation is completely configurable. > > >> > Regards, >> > Felix >> > > > > -- > Cordialement. > Philippe Mouawad.
