小心勿觸 BEA WLS 8.1 sp3 OOM 地雷

經過一段時間的壓力測試以及實驗證明，前端 AP 透過 Bea WebLogic 8.1 sp3 的 Connection Pool 取得 JDBC Connection，這種方式來存取 DB 時，會有 Memory Leak 的現象。這種情形發生在 javax.sql.DataSource.getConnection 之後，取得之 Connection 結束連線後，卻無法將佔用之記憶體全部釋放，於是時間一久，JVM Heap Memory 被吃光，便產生了 java.lang.OutOfMemoryError。

為了證明是 Bea 的問題，我特地改寫程式，透過 Jakarta Commons DBCP 元件來取得 JDBC Connection，以便與原先程式透過 Bea ConnPool 取得連線的方式作為對照組。

下面是使用 Quest JProbe Memory Debugger 分別取得的 DBCP 與 WLS ConnPool 的 Heap Memory 曲線圖：

測試個案為持續發送 Online 簡訊，經過一個小時後觀察 Heap Memory 曲線。
OnlineService 使用 WLS Connection Pool

可以看得出來 Heap memory 耗用量逐漸的上升

再來看看 OnlineService 使用 Jakarta DBCP 的情形

看得出來 Heap Memory 經過 JVM GC 皆可以正確的釋放出來

再來看看 BatchService 的情形，測試個案是兩個批次 Job 各同時處理 10 萬筆簡訊
BatchService 使用 WLS Connection Pool

Heap 耗用量一下子就飆到 80MB，之後持續上升，直到 12x MB 後，JVM 做了一次 Full GC，耗用量下降至 50MB，但馬上又飆到 12x MB 後，OOM 就發生了，兩個 Job 都無法完成。

BatchService 換成使用 Jakarta DBCP 的情形又如何呢?

跟 OnlineService 一樣平穩，至此我就確定 WLS 8.1 sp3 內部應該有 Memory Leak 的問題存在，於是求助 BEA。BEA Consultant 才給了一帖大補丸，要求上 Patch 後再觀察看看。

上了 Patch 之後，果然曲線就變得大不相同
OnlineService 使用 WLS Connection Pool + WLS8.1 sp3 patch

BatchService 使用 WLS Connection Pool + WLS8.1 sp3 patch

BatchService 換上 Patch 後，兩個批次 Job 各同時處理 10 萬筆簡訊已可正確處理完畢沒問題。

所以如果使用 WLS 8.1 sp3 的人，請小心勿觸 OOM 的地雷