有客戶說，他們通過connection pool監(jiān)控發(fā)現(xiàn)weblogic92連接池中當前連接數(current capacity)小于初始連接數(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連接池、數據庫關閉、網絡不穩(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.
       
         根據上面的異常，首先跟客戶確認是否存在過數據庫關閉、強制disable connection的操作，這些都被客戶否定了，那么最大可能的原因就是網絡不穩(wěn)定，網絡是好時壞的話，很容易造成weblogic連接池中到database server的連接中斷，從而導致connection pool被disable。

         那么為什么連接中斷會引起connection pool被disable呢？這里要談到兩個參數：CountOfTestFailuresTillFlush、CountOfRefreshFailuresTillDisable。這兩個參數在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嗎？比如數據庫因為某些原因而突發(fā)關閉，數據庫恢復后，我們是否需要手工去resume這個pool？不需要，weblogic內部實現(xiàn)了連接池的自我健康檢查功能，對于disable的connection pool，weblogic會每隔5秒鐘（DEFAULT_SCAN_UNIT）去做一次連接嘗試（嘗試創(chuàng)建一個物理連接，如果連接成功，那么這個連接會被直接放入連接池中，我們的問題就處在這兒），我們通過下面的復現(xiàn)過程來看看具體原因：

1：配置一個datasource，connection的連接數具體配置如下：


2：weblogic啟動后，我們可以看到current capacity為15，此時connection pool剛被初始化，weblogic會根據initial capacity去創(chuàng)建相應數量的連接。此時如果我們關閉數據庫，然后通過測試程序去獲取連接，你會看到我們無法拿到連接(注意我們要選上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中拿到連接，這是連接池需要做擴展，而擴展的個數就是我們設定的capacity increment（20）。再來監(jiān)控connection pool，我們就會看到連接池的current capacity為21，如下：



        那么我們能不能通過參數配置不讓connection pool不作disable呢？ 我們前面所提到的兩個參數：CountOfTestFailuresTillFlush、CountOfRefreshFailuresTillDisable，可以實現(xiàn)這樣的要求：

internal-properties用于定義一些weblogic internal的參數，這些參數無法在console上做配置。除了上面的這兩個參數，我們還可以通過internal-properties配置如下幾個參數：
    TestConnectionsOnCreate
    TestConnectionsOnRelease
    HighestNumUnavailable
    SecurityCacheTimeoutSeconds

         通過上述分析，我們可以看到這個問題不是weblogic的bug，而是因為網絡問題導致connection pool被disable，要徹底解決這個問題，可以通過網絡分析工具查出網絡問題，進而解決我們看到的這種現(xiàn)象。