有客戶說，他們通過connection pool監(jiān)控發(fā)現(xiàn)weblogic92連接池中當前連接數(shù)(current capacity)小于初始連接數(shù)(initial capacity)。從現(xiàn)象上來說，給客戶的直覺是：連接池初始化有問題，沒有幫助他們初始化他們需要的那么多連接。但他同時發(fā)現(xiàn)，幾個 connection pool中，其他pool沒有問題。拿到問題，我也懷疑這可能是weblogic的一個bug，但隨后從客戶發(fā)送過來的日志中發(fā)現(xiàn)出問題的 connection被disable過。調查后發(fā)現(xiàn)問題的確和這個pool被disable過有關，那么為什么pool被disable后，會出現(xiàn)這樣的問題呢？
首先我們看看這個pool為什么會被disable? 手工強制suspend連接池、數(shù)據(jù)庫關閉、網(wǎng)絡不穩(wěn)定等因素都可能成為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.
根據(jù)上面的異常，首先跟客戶確認是否存在過數(shù)據(jù)庫關閉、強制disable connection的操作，這些都被客戶否定了，那么最大可能的原因就是網(wǎng)絡不穩(wěn)定，網(wǎng)絡是好時壞的話，很容易造成weblogic連接池中到 database server的連接中斷，從而導致connection pool被disable。
那么為什么連接中斷會引起connection pool被disable呢？這里要談到兩個參數(shù)：CountOfTestFailuresTillFlush、 CountOfRefreshFailuresTillDisable。這兩個參數(shù)在weblogic連接池實現(xiàn)中由于控制是否、何時flush或 disable連接池，兩個都是指連續(xù)幾次失敗操作（test、refresh）后去flush或disable connection pool。注意：這是說的是連續(xù)，而不是間斷，每次成功操作（test、refresh）后，這兩個值都會被reset成0。默認情況下這兩個值均為2，即連續(xù)失敗3（2+1）次后，connection pool會被flush或disable。兩者的區(qū)別在于，flush用于清空connection pool中的所有連接（通常都是中斷的connection），當pool狀態(tài)仍保持在running狀態(tài)，而對于后者，connection pool將會變成suspend。前者對于客戶端而言，還可以從pool中reserve connection，reserve時，weblogic會嘗試重現(xiàn)創(chuàng)建連接，如果創(chuàng)建連接成功，那么客戶端就可以拿到可用的連接。而對于一個處于 suspend狀態(tài)，客戶端reserve connection的請求會直接被拒絕，收到的異常如下：
weblogic.common.resourcepool.ResourceDisabledException: Pool JDBC Data Source-0 is disabled, cannot allocate resources to applications
一個被disable的connection pool我們需要手工resume嗎？比如數(shù)據(jù)庫因為某些原因而突發(fā)關閉，數(shù)據(jù)庫恢復后，我們是否需要手工去resume這個pool？不需要，weblogic內部實現(xiàn)了連接池的自我健康檢查功能，對于disable的connection pool，weblogic會每隔5秒鐘（DEFAULT_SCAN_UNIT）去做一次連接嘗試（嘗試創(chuàng)建一個物理連接，如果連接成功，那么這個連接會被直接放入連接池中，我們的問題就處在這兒），我們通過下面的復現(xiàn)過程來看看具體原因：
1：配置一個datasource，connection的連接數(shù)具體配置如下：
圖片看不清楚？請點擊這里查看原圖（大圖）。
2：weblogic啟動后，我們可以看到current capacity為15，此時connection pool剛被初始化，weblogic會根據(jù)initial capacity去創(chuàng)建相應數(shù)量的連接。此時如果我們關閉數(shù)據(jù)庫，然后通過測試程序去獲取連接，你會看到我們無法拿到連接(注意我們要選上 TestOnReserve)，重復三次，再次去監(jiān)控connection pool。因為三次test失敗后，connection pool會被disable（狀態(tài)為suspend），如下：
3：重啟database。由于weblogic內部實現(xiàn)了connection pool的自檢功能，對于disabled的connection pool，weblogic每隔5秒鐘去做一次連接嘗試，如果連接創(chuàng)建成功，新建連接會被放入連接池，同時resume連接池。通過監(jiān)控我們可以看到，連接池狀態(tài)變成running，同時current capacity變成1,
圖片看不清楚？請點擊這里查看原圖（大圖）。
圖片看不清楚？請點擊這里查看原圖（大圖）。
4：啟動多線程測試程序，模擬2個用戶并發(fā)。第一個用戶可以從connection pool中成功拿到連接，而第二個用戶因為連接池的current capacity為1，無法直接從pool中拿到連接，這是連接池需要做擴展，而擴展的個數(shù)就是我們設定的capacity increment（20）。再來監(jiān)控connection pool，我們就會看到連接池的current capacity為21，如下：
圖片看不清楚？請點擊這里查看原圖（大圖）。
那么我們能不能通過參數(shù)配置不讓connection pool不作disable呢？我們前面所提到的兩個參數(shù)：CountOfTestFailuresTillFlush、 CountOfRefreshFailuresTillDisable，可以實現(xiàn)這樣的要求：
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的參數(shù)，這些參數(shù)無法在console上做配置。除了上面的這兩個參數(shù)，我們還可以通過internal-properties配置如下幾個參數(shù)：
TestConnectionsOnCreate
TestConnectionsOnRelease
HighestNumUnavailable
SecurityCacheTimeoutSeconds
通過上述分析，我們可以看到這個問題不是weblogic的bug，而是因為網(wǎng)絡問題導致connection pool被disable，要徹底解決這個問題，可以通過網(wǎng)絡分析工具查出網(wǎng)絡問題，進而解決我們看到的這種現(xiàn)象。
