CODEWITHSUNDEEP
javaconnectionstack-overflowconnection-poolingc3p0
Ravi Ranjan
Ravi Ranjan

Reputation: 740

Reasons why resources in c3p0 cannot get checked out?

So I was looking into the c3p0 API to debug one of our production issues which was resulting in a stack overflow error while checking out a connection.

I found below comments in BasicResourcePool class's checkoutResource method:

    /*
 * This function recursively calls itself... under nonpathological
 * situations, it shouldn't be a problem, but if resources can never
 * successfully check out for some reason, we might blow the stack...
 *
 * by the semantics of wait(), a timeout of zero means forever.
 */

I want to know what might be the reasons the resources from this pool can never get successfully checked out.

The answer might help me look into what might be going possibly wrong in my application.

Upvotes: 2

Views: 2434

Answers (1)

Steve Waldman
Steve Waldman

Reputation: 14073

So, although it's a reasonable guess, mere pool exhaustion (what happens if you leak or forget to close() Connections) won't lead to the stack overflow.

The stack overflow occurs when checkoutResource(...)

  1. finds a Connection available to check out, and "preliminarily" checks it out; then
  2. something goes wrong, indicating that the preliminarily checked-out Connection is not usable; so
  3. the function goes "back to the well", recursively calling itself to try again with a fresh Connection

The mystery is in the "something goes wrong" part. There are really two things that can go wrong:

  1. (most likely!) You have testConnectionOnCheckout set to true and all Connections are failing their Connection tests
  2. The Connection happened to be removed (e.g. expired for exceeding maxIdleTime or maxConnectionAge) from the pool during the checkout procedure

If you are seeing this, the first thing to examine is whether there is a problem with your Connection or your Connection testing regime. Try...

  1. Log com.mchange.v2.resourcepool.BasicResourcePool at DEBUG or FINE and look for Exceptions indicating inability to checkout. You can grep for A resource could not be refurbished for checkout. Alternatively, switch Connection testing regimes to testing idle Connections and on Connection check-in rather than on check-out, and watch the problem show-up in a perhaps less disruptive way.
  2. If you are doing something that would force the pool to really churn Connections, setting very short timeouts or something, it's imaginable that the race condition is biting. Check your values for configuration properties maxConnectionAge, maxIdleTime, and maxIdleTimeExcessConnections and make sure that they are reasonable or not set (i.e. left at reasonable defaults).

Upvotes: 4

Related Questions