有客户说，他们通过connection pool监控发现weblogic92连接池中当前连接数(current
capacity)小于初始连接数(initial
capacity)。从现象上来说，给客户的直觉是：连接池初始化有问题，没有帮助他们初始化他们需要的那么多连接。但他同时发现，几个connection
pool中，其他pool没有问题。拿到问题，我也怀疑这可能是weblogic的一个bug，但随后从客户发送过来的日志中发现出问题的connection被disable过。调查后发现问题的确和这个pool被disable过有关，那么为什么pool被disable后，会出现这样的问题呢？
首先我们看看这个pool为什么会被disable?
手工强制suspend连接池、数据库关闭、网络不稳定等因素都可能成为connection
pool被disable的诱因。从客户的日志中，我能看到大量的如下异常,
1：java.net.SocketException: 管道已断开
(errno:32)
2：weblogic.common.resourcepool.ResourceDisabledException: Pool
JDBC Data Source-0 is disabled, cannot allocate resources to
applications.
根据上面的异常，首先跟客户确认是否存在过数据库关闭、强制disable
connection的操作，这些都被客户否定了，那么最大可能的原因就是网络不稳定，网络是好时坏的话，很容易造成weblogic连接池中到database
server的连接中断，从而导致connection pool被disable。
那么为什么连接中断会引起connection
pool被disable呢？这里要谈到两个参数：CountOfTestFailuresTillFlush、CountOfRefreshFailuresTillDisable。这两个参数在weblogic连接池实现中由于控制是否、何时flush或disable连接池，两个都是指连续几次失败操作（test、refresh）后去flush或disable
connection
pool。注意：这是说的是连续，而不是间断，每次成功操作（test、refresh）后，这两个值都会被reset成0。默认情况下这两个值均为2，即连续失败3（2+1）次后，connection
pool会被flush或disable。两者的区别在于，flush用于清空connection
pool中的所有连接（通常都是中断的connection），当pool状态仍保持在running状态，而对于后者，connection
pool将会变成suspend。前者对于客户端而言，还可以从pool中reserve
connection，reserve时，weblogic会尝试重现创建连接，如果创建连接成功，那么客户端就可以拿到可用的连接。而对于一个处于suspend状态，客户端reserve
connection的请求会直接被拒绝，收到的异常如下：
weblogic.common.resourcepool.ResourceDisabledException:
Pool JDBC Data Source-0 is disabled, cannot allocate resources to
applications
一个被disable的connection
pool我们需要手工resume吗？比如数据库因为某些原因而突发关闭，数据库恢复后，我们是否需要手工去resume这个pool？不需要，weblogic内部实现了连接池的自我健康检查功能，对于disable的connection
pool，weblogic会每隔5秒钟（DEFAULT_SCAN_UNIT）去做一次连接尝试（尝试创建一个物理连接，如果连接成功，那么这个连接会被直接放入连接池中，我们的问题就处在这儿），我们通过下面的复现过程来看看具体原因：
http://www.blogjava.net/fjin/archive/2009/08/29/292494.html