上周有個統計程序總是報nullException,怎么查也不得要領.請教公司經理.支出大概是數據庫連接被關閉了(老大就是老大,雖然不了解java,但分析問題不是蓋的).
我用的是proxool..查google...得到下面的資料
maximum-connection-lifetime 最大連接生命周期 默認值：4小時
maximum-active-time： 最大活動時間 默認值：5分鐘
maximum-connection-count 最大連接數 默認值：15個
minimum-connection-count 最小連接數 默認值：5個
2006-05-01 03:26:06,812 WARN [HouseKeeper] proxool.default (HouseKeeper.java:149) - #0001 was active for 324234 milliseconds and has been removed automaticaly. The Thread responsible was named ‘Thread-32′, but the last SQL it performed is unknown because the trace property is not enabled.
產生如上警告的原因是:proxool中有一個參數maximum-active-time 缺省為 5 分鐘, 其含義是一個線程持有一個連接的最長時間，而不管這個連接是否處于 active 狀態, 并且如果線程的持有時間超過這個時間的之后會自動清除掉這個連接. 但是很多時候5分鐘并不夠用, 所以需要在配置文件中進行設置, 其單位為毫秒(ms).
做下記錄...
在面內容來自ubuntu中文論壇：
最近嘗試 Listen 和
Banshee 才發現，Rhythmbox 上出現的 mp3 亂碼問題依舊，而且更加嚴重，想要徹底弄清和解決必須搞清兩點，第一， mp3
標簽類型和編碼，第二，各種播放器對 mp3
標簽讀取情況，相信它們應該都有相關的開發文檔來說明，但我還是用了一個最笨的方法，就是一個一個的測試來得出結論，真理不是來自于實踐嗎？
1、了解 mp3 標簽類型和使用的編碼
首
先說 mp3 標簽類型和編碼，大家應該知道目前主要存在這幾種標準，ID3v1, ID3v2 2.3, ID3v2 2.4,
APEv2，ID3v1 只支持 ISO-8859-1 編碼 (編碼集參考)，嚴格的說它是不支持中文的 (并不代表它不能儲存中文信息，目前中文
mp3 的 ID3v1 標簽都使用這個字段來儲存 GBK/GB18030 編碼的中文信息)，而第二版 (ID3v2) 支持的格式增加了
utf-16，直到 2.4 版才開始支持 uft-8，但 ID3v2 標準沒有統一標簽內容的編碼，例如 2.4 版的 ID3v2 你可以使用
ISO-8859-1 編碼，也可以使用 utf-16/uft-8 這種 Unicode 編碼格式。做得最好的是
APEv2，它不但有很好的擴展性，而且還把編碼格式統一為 utf-8，這樣一來只要支持 APEv2 讀取的播放器播放帶有 APEv2 標簽的
mp3 就不會存在亂碼問題。
2、了解各種播放器對 mp3 標簽讀取情況
接下來研究的就是各種播放器
對這幾種標準的標簽支持程度，測試的播放器有：gnome 自帶的 Rhythmbox 0.10.0, Listen 0.5, Banshee
0.12.1+dfsg-3, Quod Libet 0.24, Exaile! 0.2.8, GMPC 0.13.0, Audacious
1.2.2。
測試的方法很簡單，用一個 mp3 文件，分別寫入不同類型的標簽 (排列組合下來共 20 多種)，在
ID3v1 和 ID3v2 2.3/2.4 中分別使用不同的編碼寫入中文信息 (如 GBK
編碼)，然后用這些播放器去讀取，得到其結果。從這次的測試結果來看，Rhythmbox 對各種 mp3 的標簽支持最好，這主要歸功于它支持
APEv2 標簽的讀取。而 Banshee 和剩下的播放器完全一樣，都不支持 APEv2 的讀取，這個就能很好的解釋為什么一些 mp3 在
Rhythmbox 上正常，在其他播放器上就會亂碼。原因是現在很多 mp3 為了兼容，都同時使用了 ID3v1 和 APEv2
標簽，Rhythmbox 讀取 ID3v1 一樣會亂碼，但它優先讀取了 APEv2 標簽，而 Banshee 這些播放器不支持 APEv2
就只能讀取 ID3v1，當然會亂碼了。
他們的共同特點就是，所依賴的 libid3tag 庫完全按照 ID3
標準來讀取標簽內容。不管使用何種標準的標簽，只要是讀取以 Unicode 編碼的中文內容，肯定沒有問題，遇到 GBK/GB18030
編碼的中文內容時，還是把它當成 ISO-8859-1 編碼來讀取，不亂才怪。
ps: Vista 上的 WMP 不支持
ID3v2 2.4 和 APEv2 標簽的讀取，但它很聰明不能讀取就用文件名代替，千千靜聽支持全系列標簽的讀取，但不支持以 ID3v2 2.4
標準的寫入，不知道即將發布的 5.0 有變化沒有。foobar2000 v0.9.4.3 支持全系列標簽的讀取，默認使用 ID3v2 2.4
( utf-8 ) 寫入，不愧被譽為經典。
3、解決辦法
既然明白了亂碼的原因，就得找解決辦法，一種
辦法就像 Win 上的播放器一樣，可以根據本地的編碼方式來解碼，或使用一些其他轉碼機制，要不還可以選擇優先讀取順序。以上測試的播放器中除了
Audacious 外其他都不支自定義編碼讀取功能。另外一個解決辦法就是把 mp3 標簽轉換為 Unicode
編碼，這種方式既簡單又支持標準，推薦大家使用。如果像 Banshee 一樣支持顯示文件路徑也可以解決亂碼問題，但這不是根本之道。
目前發現有 2 個工具可以把標簽轉換為 Unicode 編碼，而且都支持批量轉換。
1) 一個是周楓用 java 編寫的 ID3iconv 0.2.1，最后更新時間為 2004/2/20。
使用方法：
java -jar ~/id3iconv-0.2.1.jar -e gbk *.mp3
如果想轉換當前目錄下的所有 mp3 (包括子目錄)：
find . -iname "*.mp3" -execdir java -jar ~/id3iconv-0.2.1.jar -e gbk {} ";
* 注意以上 ~/id3iconv-0.2.1.jar 位置根據自己情況而定
* 相信現在大陸絕大多數能找到的 mp3 標簽都是以 GBK/GB18030 編碼，使用 -e gbk 來處理就夠了，當然你也可以使用 -e gb18030 來處理。
* -e gbk 參數是代表把 GBK 編碼的標簽轉換為 Unicode 編碼，本身是 Unicode 編碼的就不轉換。如果需要轉換其他編碼的文件可以自行修改，如改為 Big5。
* 經測試，轉換后為 2.3 版的 ID3v2，編碼格式為 uft-16
2) 另外一個是用 Python 寫的 “Mutagen”，目前最新版本 1.11，Ubuntu 7.04 源里也帶有 1.10 版本的 Mutagen，可以用這個命令來安裝：
sudo apt-get install python-mutagen
ps:安裝 Quod Libet 和 Listen 都必須這個
使用方法：
mid3iconv -e gbk *.mp3
如果想轉換當前目錄下的所有 mp3 (包括子目錄)：
find . -iname "*.mp3" -execdir mid3iconv -e gbk {} ";
* 相信現在大陸絕大多數能找到的 mp3 標簽都是以 GBK/GB18030 編碼，使用 -e gbk 來處理就夠了，當然你也可以使用 -e gb18030 來處理。
* -e gbk 參數是代表把 GBK 編碼的標簽轉換為 Unicode 編碼，本身是 Unicode 編碼的就不轉換。如果需要轉換其他編碼的文件可以自行修改，如改為 Big5。
* 經測試，轉換后為 2.4 版的 ID3v2，編碼格式為 uft-16
*
不過它會同時用 Unicode 編碼填滿 D3v1, ID3v2, APEv2 標簽，但是 ID3v1 又不支持中文的 Unicode
編碼，所以轉換后的 ID3v1 標簽全是問號。所以最好加上 –remove-v1 參數，轉換后刪除 ID3v1 標簽。
mid3iconv -e gbk --remove-v1 *.mp3
我的使用情況：
我選擇使用第二種方法，網落安裝，快捷阿。呵呵，提醒使用的時候， find . -iname "*.mp3" -execdir mid3iconv -e gbk {} ";
這個語句后面是有 ‘；’這個標點符號的。