my team saw this same thing in production - there was code that never closed the SQL connection after it was created... 150+ connections spike all at once, took out the pool. Not sure if that's your issue, but thought i'd mention it ________________________________________________
Kevin Huntly Email: kmhun...@gmail.com Cell: 716/424-3311 ________________________________________________ -----BEGIN GEEK CODE BLOCK----- Version: 1.0 GCS/IT d+ s a C++ UL+++$ P+(++) L+++ E--- W+++ N+ o K(+) w--- O- M-- V-- PS+ PE Y(+) PGP++(+++) t+ 5-- X-- R+ tv+ b++ DI++ D++ G++ e(+) h--- r+++ y+++* ------END GEEK CODE BLOCK------ On Mon, Apr 17, 2023 at 7:07 PM Akshay Mishra <akshay.mis...@nutanix.com> wrote: > Hello Tomcat Community! > > > Tomcat Version: 9.0.70 > > Our Tomcat web service started exhausting the max connections allowed to > the backend datastore (Postgres). > > From the logs, we don’t see any 1 thread requesting lot of connections. > Nor do we see too many threads requesting a new connection. > We collected thread dumps (at a fixed interval of 5 mins) and they do not > point to too many threads requesting connections. > > We suspect someone could be leaking connections but we are unclear on how > to narrow that down especially since the thread dump was inconclusive > > We added parameters like “removeAbandoned”, “removeAbandonedTimeout” and > “ResetAbandonedTimer” to our datasource config and the results were > encouraging - we don't see the pool getting exhausted but are concerned > this might mask a larger problem in case there are connection leaks in our > service. > > It would be great if the community has any thoughts on these new > parameters. Or on way to narrow down the problem to isolate connection > leaks. > > Any help is appreciated. Thanks > > Akshay >
