在上一个问题之后，我对春天＆amp; iptables命令Spring transaction hangs for iptables command
我发现这是getConnection功能的问题，其中使用以下命令时idle-connection与checkout-connection测试混合
iptables -A INPUT -p tcp --destination-port <database-listener-port> -s <database-host-ip>
在BasicResourcePool类的java文档中，我看到确实可能存在这样的问题。而这正是我得到这种无限循环的地方
private synchronized Object prelimCheckoutResource( long timeout )
...
// this is a hack -- but "doing it right" adds a lot of complexity, and collisions between
// an idle check and a checkout should be relatively rare. anyway, it should work just fine.
if ( idleCheckResources.contains( resc ) )
我的问题是，这样的问题（数据包是DRP编辑的）预计会在代码中得到修复，还是你认为运行这样的命令是错误的，当数据库主机不可用时我们可以使用另一个命令模拟在现实世界中更期待。
感谢您的意见。
答案 0 :(得分：0)
所以你在这里向c3p0展示一个不寻常且具有挑战性的失败模式。空闲检查没有失败。他们也没有成功。当你强制丢弃传入的数据包时，它们会无限期地挂起。 （我假设您使用earlier post中的完整命令，该命令指定丢弃传入的数据包。）c3p0要求测试在合理的时间内成功或失败并显示异常。悬挂提出挑战。
你可以通过设置c3p0配置参数maxAdministrativeTaskTime来解决这些挑战。不幸的是，checkoutTimeout无济于事：它只会超时客户端等待（）使用不可用的连接，它不会被设计为注意到客户端从未停留过 - 结束，挂起测试。
请注意，您创建的此故障模式与典型的数据库中断无关。在真正的数据库中断中，由于传出的tcp连接被拒绝，空闲连接的测试将立即失败并显示异常。
另请注意，上一个问题中的配置与有效的c3p0配置不太相似。看起来你正在混合来自不同池的配置参数，并且不清楚你设置的参数甚至是你的游泳池。当c3p0池初始化时，它们会将配置信息转储到INFO的日志中。请检查并确保池转储的配置是您要设置的配置。