为什么无法检出c3p0中的资源? [英] Reasons why resources in c3p0 cannot get checked out?

问题描述

所以我一直在研究c3p0 API来调试我们的生产问题之一，这在签出连接时导致堆栈溢出错误.

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.

我在 BasicResourcePool 类的 checkoutResource 方法中找到以下注释:

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.
 */

我想知道该池中的资源永远无法成功检出的原因是什么.

答案可能有助于我研究应用程序中可能出了什么问题.

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

推荐答案

所以，尽管这是一个合理的猜测，但仅池耗尽(如果您泄漏或忘记关闭()连接会发生什么)不会导致堆栈溢出

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.

当 checkoutResource(...)

1. 找到一个可用于检出的连接，并初步"检出它；然后
2. 出了点问题，表明初步检出的Connection不可用；所以
3. 函数恢复正常"，递归地调用自身以使用新的Connection再次尝试

奥秘在于出了点问题"部分.确实有两件事可能出错:

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

1. (最有可能！)您已将 testConnectionOnCheckout 设置为 true ，并且所有连接均未通过其连接测试
2. 在结帐过程中，碰巧从池中删除了连接(例如，由于超过 maxIdleTime 或 maxConnectionAge 而过期)

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

如果您看到此消息，那么首先要检查的是Connection或Connection测试方案是否存在问题.试试...

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. 在 DEBUG 或 FINE 上登录 com.mchange.v2.resourcepool.BasicResourcePool ，然后查找表示无法检出的异常.您可以grep表示无法翻新资源以结帐.或者，将连接测试方式切换为测试空闲的连接，并在连接检入而不是在检出时进行测试，并以破坏性较小的方式观察问题的出现.
2. 如果您执行的操作会迫使连接池真正中断，或者设置很短的超时时间或其他原因，则可以想象竞争状况令人生畏.检查配置属性的值 maxConnectionAge ，maxIdleTime 和 maxIdleTimeExcessConnections ，并确保它们是合理的或未设置的(即保留合理的默认值).

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).

这篇关于为什么无法检出c3p0中的资源?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！