> On Mar 1, 2018, at 3:33 PM, Shawn Heisey <apa...@elyograg.org> wrote: > > We have been having some problems lately where our MySQL server hits the > max connection limit (600) and then everything breaks. When I look into > the problem, I find that our application servers have each made nearly a > hundred connections to the DB and haven't closed any of them for hours. > > I'm also using connection pooling in my programs, with the latest DBCP > version. Those servers don't open nearly as many connections, and have > idle eviction to keep the connection count down. But when the limit is > reached, these programs suddenly stop working too. > > Investigating these problems, I manage to get connected and kill off the > surplus of idle connections, and everything starts working. > > Today, a couple of days after the last incident, I realized that we > should *NOT* be having these problems -- because we're using connection > pooling. The application has open and idle connections to the DB server > ... so why is trying to open MORE connections (and obviously failing) > instead of using one of the perfectly good connections that's already > sitting there, unused? > > I'm writing here specifically for DBCP on my programs, so I know you > guys probably can't help with Tomcat's connection pooling ... but for > either case my question stands: Why isn't connection pooling doing its job?
Best to start by posting your pool config. One thing to bear in mind is that “idle” from The dB perspective does not mean the same thing as idle from the pool’s perspective. In addition to genuinely abandoned connections, another way that applications can hog dB connections is to check them out and hold them for a long time while not using them. On the dB engine side these will show as idle, but as they are checked out to clients they are not available in the pool. When you are having the problem, what does dB one report as numidle? Phil > > Thanks, > Shawn > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-unsubscr...@commons.apache.org > For additional commands, e-mail: user-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
