有客戶說，他們通過connection pool監(jiān)控發(fā)現(xiàn)weblogic92連接池中當(dāng)前連接數(shù)(current capacity)小于初始連接數(shù)(initial capacity)。從現(xiàn)象上來說，給客戶的直覺是：連接池初始化有問題，沒有幫助他們初始化他們需要的那么多連接。但他同時(shí)發(fā)現(xiàn)，幾個(gè)connection pool中，其他pool沒有問題。拿到問題，我也懷疑這可能是weblogic的一個(gè)bug，但隨后從客戶發(fā)送過來的日志中發(fā)現(xiàn)出問題的connection被disable過。調(diào)查后發(fā)現(xiàn)問題的確和這個(gè)pool被disable過有關(guān)，那么為什么pool被disable后，會(huì)出現(xiàn)這樣的問題呢？

        首先我們看看這個(gè)pool為什么會(huì)被disable? 手工強(qiáng)制suspend連接池、數(shù)據(jù)庫關(guān)閉、網(wǎng)絡(luò)不穩(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ù)上面的異常，首先跟客戶確認(rèn)是否存在過數(shù)據(jù)庫關(guān)閉、強(qiáng)制disable connection的操作，這些都被客戶否定了，那么最大可能的原因就是網(wǎng)絡(luò)不穩(wěn)定，網(wǎng)絡(luò)是好時(shí)壞的話，很容易造成weblogic連接池中到database server的連接中斷，從而導(dǎo)致connection pool被disable。

         那么為什么連接中斷會(huì)引起connection pool被disable呢？這里要談到兩個(gè)參數(shù)：CountOfTestFailuresTillFlush、CountOfRefreshFailuresTillDisable。這兩個(gè)參數(shù)在weblogic連接池實(shí)現(xiàn)中由于控制是否、何時(shí)flush或disable連接池，兩個(gè)都是指連續(xù)幾次失敗操作（test、refresh）后去flush或disable connection pool。注意：這是說的是連續(xù)，而不是間斷，每次成功操作（test、refresh）后，這兩個(gè)值都會(huì)被reset成0。默認(rèn)情況下這兩個(gè)值均為2，即連續(xù)失敗3（2+1）次后，connection pool會(huì)被flush或disable。兩者的區(qū)別在于，flush用于清空connection pool中的所有連接（通常都是中斷的connection），當(dāng)pool狀態(tài)仍保持在running狀態(tài)，而對(duì)于后者，connection pool將會(huì)變成suspend。前者對(duì)于客戶端而言，還可以從pool中reserve connection，reserve時(shí)，weblogic會(huì)嘗試重現(xiàn)創(chuàng)建連接，如果創(chuàng)建連接成功，那么客戶端就可以拿到可用的連接。而對(duì)于一個(gè)處于suspend狀態(tài)，客戶端reserve connection的請(qǐng)求會(huì)直接被拒絕，收到的異常如下：
weblogic.common.resourcepool.ResourceDisabledException: Pool JDBC Data Source-0 is disabled, cannot allocate resources to applications

        一個(gè)被disable的connection pool我們需要手工resume嗎？比如數(shù)據(jù)庫因?yàn)槟承┰蚨话l(fā)關(guān)閉，數(shù)據(jù)庫恢復(fù)后，我們是否需要手工去resume這個(gè)pool？不需要，weblogic內(nèi)部實(shí)現(xiàn)了連接池的自我健康檢查功能，對(duì)于disable的connection pool，weblogic會(huì)每隔5秒鐘（DEFAULT_SCAN_UNIT）去做一次連接嘗試（嘗試創(chuàng)建一個(gè)物理連接，如果連接成功，那么這個(gè)連接會(huì)被直接放入連接池中，我們的問題就處在這兒），我們通過下面的復(fù)現(xiàn)過程來看看具體原因：

1：配置一個(gè)datasource，connection的連接數(shù)具體配置如下：


2：weblogic啟動(dòng)后，我們可以看到current capacity為15，此時(shí)connection pool剛被初始化，weblogic會(huì)根據(jù)initial capacity去創(chuàng)建相應(yīng)數(shù)量的連接。此時(shí)如果我們關(guān)閉數(shù)據(jù)庫，然后通過測試程序去獲取連接，你會(huì)看到我們無法拿到連接(注意我們要選上TestOnReserve)，重復(fù)三次，再次去監(jiān)控connection pool。因?yàn)槿蝨est失敗后，connection pool會(huì)被disable（狀態(tài)為suspend），如下：




3：重啟database。由于weblogic內(nèi)部實(shí)現(xiàn)了connection pool的自檢功能，對(duì)于disabled的connection pool，weblogic每隔5秒鐘去做一次連接嘗試，如果連接創(chuàng)建成功，新建連接會(huì)被放入連接池，同時(shí)resume連接池。通過監(jiān)控我們可以看到，連接池狀態(tài)變成running，同時(shí)current capacity變成1,





4：啟動(dòng)多線程測試程序，模擬2個(gè)用戶并發(fā)。第一個(gè)用戶可以從connection pool中成功拿到連接，而第二個(gè)用戶因?yàn)檫B接池的current capacity為1，無法直接從pool中拿到連接，這是連接池需要做擴(kuò)展，而擴(kuò)展的個(gè)數(shù)就是我們?cè)O(shè)定的capacity increment（20）。再來監(jiān)控connection pool，我們就會(huì)看到連接池的current capacity為21，如下：



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

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

         通過上述分析，我們可以看到這個(gè)問題不是weblogic的bug，而是因?yàn)榫W(wǎng)絡(luò)問題導(dǎo)致connection pool被disable，要徹底解決這個(gè)問題，可以通過網(wǎng)絡(luò)分析工具查出網(wǎng)絡(luò)問題，進(jìn)而解決我們看到的這種現(xiàn)象。