c3p0 中的资源无法签出的原因？

Question

所以我正在研究 c3p0 API 来调试我们的一个生产问题，该问题导致在检查连接时出现堆栈溢出错误。

我在BasicResourcePool类的checkoutResource方法下面找到了cmets：

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

我想知道这个池中的资源永远无法成功签出的原因可能是什么。

答案可能会帮助我了解我的应用程序中可能出现的问题。

Answer 1

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

checkoutResource(...)时发生堆栈溢出

1. 找到一个可以检出的连接，并“初步”检出它；那么
2. 出现问题，说明初步签出的Connection不可用；所以
3. 函数“回到井中”，递归调用自身以使用新的连接重试

谜团在于“出现问题”部分。确实有两件事可能会出错：

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

如果您看到这种情况，首先要检查的是您的 Connection 或您的 Connection 测试制度是否存在问题。试试……

1. 在DEBUG 或FINE 记录com.mchange.v2.resourcepool.BasicResourcePool 并查找指示无法结帐的异常。您可以使用 grep 搜索 A resource could not be refurbished for checkout. 或者，switch Connection testing regimes 来测试空闲连接并在连接签入而不是签出时测试，并以一种可能不那么破坏性的方式观察问题的出现。
2. 如果您正在做的事情会迫使池真正搅动连接，设置非常短的超时或其他什么，可以想象竞争条件正在咬人。检查configuration propertiesmaxConnectionAge、maxIdleTime 和maxIdleTimeExcessConnections 的值，并确保它们设置合理或未设置（即保留合理的默认值）。