tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From marko lugarič <marko.luga...@gmail.com>
Subject Re: Tomcat connection pool "bleeding" under heavy load
Date Wed, 20 Nov 2013 17:07:29 GMT
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 <
chris@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message