Hello I have repeated the test with logAbandoned set to "true" and left it half hour after pool is empty. There are a lot of exceptions (Pool empty. Unable to fetch a connection in 15 seconds and Pool wait interrupted) but i don't know what exactly to search (search with Abandoned did not produce anything). I have already tried using StatementFinalizer interceptor but it did not do anything to prevent pool from being empty.
regards, marko On Wed, Nov 20, 2013 at 2:28 PM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Marko, > > On 11/20/13, 8:14 AM, marko lugarič wrote: > > 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). > > Having logAbandoned set to "true" is pretty critical, here. Please > re-enabled it and re-test. > > In a separate thread, markt pointed out that Tomcat-pool allows you to > leak resources much more readily than the dbcp-based pool if you don't > exercise proper resource management. I posted a link to my old blog > post on the subject, and I'll post it here again as well: > > > http://blog.christopherschultz.net/index.php/2009/03/16/properly-handling-pooled-jdbc-connections/ > > If you have sloppy JDBC resource management, you are going to waste > resources on both the client and the server unless you have a pool > that spends inordinate resources tracking everything to clean up after > your sloppy code. > > Tomcat-pool has a StatementFinalizer interceptor > ( > http://tomcat.apache.org/tomcat-7.0-doc/jdbc-pool.html#org.apache.tomcat.jdbc.pool.interceptor.StatementFinalizer > ) > that you can use to help clean-up the messes that you create. > > It would be better, though, to clean-up your resources. > > Dan Mikasa suggested using a tool like Findbugs on your code, which > easily identifies things like potential leaks in JDBC resources. It's > well worth the time to download and run it. (Besides, all you need is > a JAR file with your code and you can just say "scan the JAR file for > bugs". It does not require a great deal of setup). > > - -chris > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.15 (Darwin) > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBCAAGBQJSjLjpAAoJEBzwKT+lPKRYdh8QAKuJ95EY3YktG0GsM+Vp/PYK > P3y4t88ImLtWYIWo2mfeAUaY5sh371yC8ihGcy2m6d/qv+s+lfWpKf/MlaOycvBk > 5203PRPvSSDI9Tlh19IA6/9urf6YsXDcw62j7X6oOoTQN2GoilhovIl7jUPcTc2M > dqizRvJDmsWJMODeL0E1Ne1P84AnilNhELL6RPJ09UXYAsbyyFZasALAiwuCXyyt > fRblQ4pHMTWWK6e7Hrhp93iK9gE1FGtPoQISq9T2GsazzHr8aFavCthFYq03mzRf > WOYrq1lZsycJKgu0+7xm9xv4KCCVbJX/wCyVVuuhF4s/sZWRioWDyAhn3tx88sFM > 60u5L95y7zVbxlszE7lmq83B5eyX+3llMIDol32r+T7nJhOo45asyAwOJkF5n8n/ > UQFJhl16I5KTnklq0IM1lol5oDjI9qt+wcqolfUD0FWL7Z5IYFnCpNpo9/9kW+gc > UNbIbHEm1fOW7bWbpD9KtzLraRLzRS/H9EeVMRr/DRKlna79RYnhi/ErntJrg2cD > CzaGRq4y+f7ZkyUmArHio6SpifiQeYUgAhwsP6MH9hxNFleoIDa+Xdp4u4Li8RcM > yM8lNRPLw+mo2fultaA8iYRLVWcul/GbJajUbKEwZh0bV/pVAqPU40U5YuAiEnUc > qBtkr4U+Lms008/vnc01 > =4seS > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
