Hello The tests are run in the following manner: around 5 min to start the server and connect all clients. Then I can apply load from clients: on the graph I applied only half load for first seven minutes an then full load but this is not required - I can go with full load after all clients connect. So once full load is applied usually in less then 5 minutes pool has no connections (it) - then I can leave it for half hour (tested today) and nothing changes (0 empty and zero active connections). But i didn't have logAbandonded set - I can test this too if you think there will be difference. In the usual test when i saw that there is no connections I turned off server (2 - 5 minutes later).
On Wed, Nov 20, 2013 at 2:35 AM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Marko, > > On 11/19/13, 10:16 AM, marko lugarič wrote: > > About using useEquals="false" property I guess we defined when we > > started using this pool. After reading the documentation i guess it > > is better to leave it out (it has no effect on the test - i tested > > it). > > Okay. Let me know if you discover a reason to set that option again. > > > We dont have long running queries because there is not much data > > and all operations are fast (the longest one are ranging from 1 to > > 2 seconds: i used slowqueryinterceptor and sql server profiler). > > The test always starts with empty database. > > Ok. > > > I never got any abandoned messages in the stdout or catalina.out > > (logabandoned set to true) - I put everything that is not from our > > application and is at least on INFO level to catalina.out. I added > > org.apache.tomcat.jdbc.pool package to logs on TRACE level and the > > only line that is repeating (5 times) is: 2013-11-19 15:25:24,764 > > DEBUG [main] org.apache.tomcat.jdbc.pool.PooledConnection > > connectUsingDriver(): Instantiating driver using class: > > com.microsoft.sqlserver.jdbc.SQLServerDriver > > [url=jdbc:sqlserver://*****;databaseName=chiTestDB] > > That will be filling the pool. It's clear that the pool is emptying > and never re-filling, or you'd get more of the above messages. > > > Dont know if there is really that little logging in connection > > pool. In that case debugging looks like the only option? > > Perhaps, but I think you might be able to get more information from > the pool. > > > About C3P0 pool:we are under the impression that > > org.apache.tomcat.jdbc.pool is the only way to go (production > > quality) after reading The Tomcat JDBC Connection Pool page (after > > your comment i guess this is not true and commons-dbcp is > > production quality alternative?). > > IMO the Tomcat-pool documentation overstates the awfulness of the > dbcp-based pool. We use it for production and it works just fine. > We've never had a problem with the pool that we didn't cause by our > own bad webapp code (e.g. not returning connections) or due to > long-running queries triggering the "abandoned" alarms. OTOH, our site > does not run an enormously-high transaction rate, either. > > > So since this did not work for us we started looking for > > alternative and C3P0 pooped up in connection pool comparisons or in > > some stackoverflow thread. > > Just note that C3P0 is self-described "beta" software. > > So, back to the problem: how long does your test run? Do you allow the > server to cool-down after your tests? I'm wondering if you are > shutting-down the server before it has a chance to complain about the > abandoned connections. > > I've never used Tomcat-pool, so I'm not exactly sure what to expect, > but the abandoned stuff should probably work exactly as described in > the documentation, and roughly equivalently to the dbcp-based pool. > > - -chris > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.15 (Darwin) > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBCAAGBQJSjBHIAAoJEBzwKT+lPKRYQ4AQALKwD6/Cko6t7di8oXZS8sKO > pdHc2AQhrPbg95stygZiBm8lH4ds7RhwslD7JcWafSUfln/smLJO0gaV+M3PNDzX > gQs/zqZyHtEW4vD2oIiL+CY/I0kbAON3tRbXFBjfJKikeINiIrTYGvm8h2dkhq4X > WLijKrsh/qy96RkmUYPd0o1RsmraYCeGdSNpA96vycgrb89YHiJj07BkinKdhxTQ > 903huox7ZspSGR0bl/+zEchHKj5AO9D9QELas6Z3qGwd+O7A5rxcX5YHsEXkNX6z > mTwvAHzobdLXtu7LS6i+td46hFd0QurutnhrOAIZpoHNz7kItRZGDxYB296A5lY/ > xdOzGXKMMaTM854hvLuSPy6zkU2S235+KEA6sVi9HpNtP42yoPbdJfM3thHcKrxB > Zm/8z6DrMtHFXBRbCFE7PGds9tymCvZx3/n/Zv5a6jm2iSEOLcSSKGnvQG663029 > l2XEGQyZufo+YsY9kQN+zxwSdbBl381PC8YXB+Dh2VR+LYaEuJqpxIkJjR+gIdiT > JhXm4qSAYVsPDesG7GwXMwY9oFfpVvOzvv8KbH1AM/GaiLBLclTmHWZ8xw+alD7i > HlR0M9gJ2dw6x6hYbv+wguBksqLxhLFOe+j6rekd7esyMP71nZh4TT4rf+r4XrGe > 5RkJAULb0vE+ipAgZT/P > =Vjf7 > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
