最近的項(xiàng)目中有用到libvirt的java包進(jìn)行l(wèi)ibvirt的遠(yuǎn)程命令調(diào)用，進(jìn)行kvm的管理。我們的測試人員一個(gè)偶然的機(jī)會下測試出來，在控制連接狀態(tài)的時(shí)候，可能存在一個(gè)嚴(yán)重的bug，由于界面上的flex應(yīng)用在每次點(diǎn)擊虛擬機(jī)節(jié)點(diǎn)的時(shí)候，會導(dǎo)致對后臺的remote service進(jìn)行大約3-4次的調(diào)用，而這些remote service中會利用libvirt的結(jié)構(gòu)進(jìn)行結(jié)果的獲取，我們?yōu)榱颂岣咝剩瑢ibvirt的鏈接進(jìn)行了保持，而不是每次都進(jìn)行重連，以減少性能的損耗。
存在這樣的情況，當(dāng)網(wǎng)絡(luò)正常的時(shí)候，建立起來的connection，一直在內(nèi)存中駐留，此時(shí)如果拔掉網(wǎng)線，這個(gè)鏈接也不會斷開，由于內(nèi)存中這個(gè)connection的值也不為空，無法判斷鏈接是否斷開，所以在此點(diǎn)擊界面的時(shí)候，一點(diǎn)調(diào)用了libvirt的接口，就會一直卡住界面多點(diǎn)擊幾次后，tomcat的所有可服務(wù)線程就都卡住了，導(dǎo)致整個(gè)界面無法使用。
解決方法為：啟動一個(gè)線程由于實(shí)時(shí)的檢測主機(jī)的斷開連接狀態(tài)，當(dāng)狀態(tài)不正常的時(shí)候，在獲取connection的方法中直接拋出異常，阻止后續(xù)的邏輯的執(zhí)行。但是這樣只能解決狀態(tài)問題，不能解決在這個(gè)狀態(tài)獲取的間隙中的界面點(diǎn)擊問題，查找到資料發(fā)現(xiàn)tomcat的線程池模型也許可以幫忙，于是將線程池用上了，測試過后，終于發(fā)現(xiàn)可以了。
據(jù)說tomcat7可以檢測哪個(gè)線程被卡死了，但是由于條件顯示沒有將產(chǎn)品中的tomcat6環(huán)境升級為tomcat7，所以這個(gè)也就不可用了。
具體修改方法：
Executor name="tomcatThreadPool" namePrefix="catalina-exec-" maxThreads="150" minSpareThreads="4"/gt
取消掉這段的注釋，然后可以修改maxThreads和minSpareThreads兩個(gè)參數(shù)為你想要的值，maxThreads比較簡單允許的最多線程數(shù)
通常150應(yīng)該足夠了，后面的這個(gè)參數(shù)呢，表示最小的駐留服務(wù)線程數(shù)，也就是說這些線程會一直等待服務(wù)。/p>
p>Connector executor="tomcatThreadPool" port="8080" protocol="HTTP/1.1"
connectionTimeout="20000" maxTreads="500" minSpareThreads="30" maxSpareThreads="50"
URIEncoding="UTF-8" keepAliveTimeout="15000"
redirectPort="8443" />/p>
p>修改Connector節(jié)點(diǎn)，增加executor="tomcatThreadPool"，maxThreads,minSpareThreads,maxSpareThreads，keepAliveTimeout等參數(shù)的配置
這樣就基本上解決了問題，參數(shù)具體含義呢，其中兩個(gè)和上面提到的意義是一樣的，executor表示對上面的那個(gè)Executor節(jié)點(diǎn)的引用，所有這個(gè)配置的線程都會在那個(gè)池中。
keepAliveTimeout表示每個(gè)線程能被卡住的最長時(shí)間，也就是能存活的最長時(shí)間。
有了上述修改后，我們的tomcat就再也不會被libvirt線程卡住了，一旦卡住，也只是15秒的一個(gè)線程，除非能同時(shí)請求操過500個(gè)線程，否則tomcat都能正常的提供服務(wù)了，只是上述參數(shù)沒經(jīng)過調(diào)優(yōu)，性能各方面都沒有測試，只是臨時(shí)解決，具體數(shù)值的大小，還是需要按照實(shí)際情況，經(jīng)過多組數(shù)據(jù)的測試對比后然后確定一個(gè)值。
