ERROR - java.sql.SQLException: Connection has been administratively disabled. Try later. 
ERROR - Could not release connection to pool:java.lang.NullPointerException 

Could not get JDBC Connection; nested exception is weblogic.jdbc.extensions.PoolDisabledSQLException: weblogic.common.resourcepool.ResourceDisabledException: Pool bjjcsj is disabled, cannot allocate resources to applications..

ERROR - Hibernate operation: Cannot open connection; uncategorized SQLException for SQL [???]; SQL state [null]; error code [0]; weblogic.common.resourcepool.ResourceDisabledException: Pool bjjcsj is disabled, cannot allocate resources to applications..; nested exception is weblogic.jdbc.extensions.PoolDisabledSQLException: weblogic.common.resourcepool.ResourceDisabledException: Pool bjjcsj is disabled, cannot allocate resources to applications.. (LogHandler.java:72) 

pool被disabled的原因大致有3：
1、连接被手工强制suspend；
2、网络不通；
3、程序在执行过程中被挂起；

 

有客户说，他们通过connection pool监控发现weblogic92连接池中当前连接数(current capacity)小于初始连接数(initial capacity)。从现象上来说，给客户的直觉是：连接池初始化有问题，没有帮助他们初始化他们需要的那么多连接。但他同时发现，几个 connection pool中，其他pool没有问题。拿到问题，我也怀疑这可能是weblogic的一个bug，但随后从客户发送过来的日志中发现出问题的 connection被disable过。调查后发现问题的确和这个pool被disable过有关，那么为什么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

　　2：weblogic启动后，我们可以看到current capacity为15，此时connection pool刚被初始化，weblogic会根据initial capacity去创建相应数量的连接。此时如果我们关闭数据库，然后通过测试程序去获取连接，你会看到我们无法拿到连接(注意我们要选上 TestOnReserve)，重复三次，再次去监控connection pool。因为三次test失败后，connection pool会被disable（状态为suspend），如下：

　3：重启database。由于weblogic内部实现了connection pool的自检功能，对于disabled的connection pool，weblogic每隔5秒钟去做一次连接尝试，如果连接创建成功，新建连接会被放入连接池，同时resume连接池。通过监控我们可以看到，连接池状态变成running，同时current capacity变成1,

　　4：启动多线程测试程序，模拟2个用户并发。第一个用户可以从connection pool中成功拿到连接，而第二个用户因为连接池的current capacity为1，无法直接从pool中拿到连接，这是连接池需要做扩展，而扩展的个数就是我们设定的capacity increment（20）。再来监控connection pool，我们就会看到连接池的current capacity为21，如下：

　　图片看不清楚？请点击这里查看原图（大图）。

　　那么我们能不能通过参数配置不让connection pool不作disable呢？我们前面所提到的两个参数：CountOfTestFailuresTillFlush、 CountOfRefreshFailuresTillDisable，可以实现这样的要求：

　1　　　<internal-properties>
2　　　　　　　　　　　<property>
3　　　　　　　　　　　　　<name>CountOfTestFailuresTillFlush</name>
4　　　　　　　　　　　　　<value>10</value>
5　　　　　　　　　　　</property>
6　　　　　　　　　　　<property>
7　　　　　　　　　　　　　<name>CountOfRefreshFailuresTillDisable</name>
8　　　　　　　　　　　　　<value>20</value>
9　　　　　　　　　　　</property>
10　　　</internal-properties>

　　internal-properties用于定义一些weblogic internal的参数，这些参数无法在console上做配置。除了上面的这两个参数，我们还可以通过internal-properties配置如下几个参数：

　　　　TestConnectionsOnCreate
TestConnectionsOnRelease
HighestNumUnavailable
SecurityCacheTimeoutSeconds

 

　　通过上述分析，我们可以看到这个问题不是weblogic的bug，而是因为网络问题导致connection pool被disable，要彻底解决这个问题，可以通过网络分析工具查出网络问题，进而解决我们看到的这种现象。