commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <>
Subject Re: [DBCP] Connection pool not behaving as I expect
Date Thu, 01 Mar 2018 23:46:51 GMT
On Thu, Mar 1, 2018 at 3:33 PM, Shawn Heisey <> 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?

I do not think this is a question I, or anyone here, can answer
generically. I can read between that lines that you must feel frustrated
and I certainly empathize with that. I think you might want to debug your
application and come up with some parameters for us to start helping you. A
reproducible example is always best but I understand it might be hard to
provide in this particular case.


> Thanks,
> Shawn
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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