05 2010 檔案
摘要: 近期自己折騰自己，放著正統(tǒng)的maven + junit不用，卻準(zhǔn)備用ant + ivy 替代maven做依賴管理，用testng替代junit做單元測試。
閱讀全文
摘要: 眾所周知，對于高動態(tài)高可擴(kuò)展的應(yīng)用，OSGI是一個(gè)非常好的平臺。但是，也因此增加了復(fù)雜性，開發(fā)中對service的依賴變得復(fù)雜。這也是 service的關(guān)系管理成為OSGI中一個(gè)非常重要的部分，我們來看看OSGI中service依賴關(guān)系管理的方式。篇幅原因，只關(guān)注發(fā)展歷程，不具體介紹每個(gè)方式的詳細(xì)實(shí)現(xiàn)細(xì)節(jié)。
概括的說，目前在OSGI中主要有以下幾種service依賴關(guān)系管理的方法：
1. Service listener
2. Service binder
3. Dependency Manager
4. Declarative Services
5. iPOJO
6. blueprint
閱讀全文
摘要: 當(dāng)時(shí)實(shí)際上，我們在檢查ThreadDeath的調(diào)用信息時(shí)，說明這個(gè)出現(xiàn)init()錯(cuò)誤的filter還是被glassfish正常調(diào)用去執(zhí)行doFilter()方法，這里和j2ee API的要求是不符合的。有點(diǎn)奇怪的是，glassfish一向是以嚴(yán)格遵循j2ee規(guī)范而著稱，居然在這里一反常態(tài)。
而更令人 郁悶的是，glassfish在處理這個(gè)有filter初始化出現(xiàn)ServletException異常的webapp時(shí)的前后表現(xiàn)：首先這個(gè) webapp的啟動沒有問題，狀態(tài)正常。filter也被認(rèn)為可以正常工作并加入了filter鏈。webapp中的功能正常，可以正常的接收請求并轉(zhuǎn)發(fā)給內(nèi)容業(yè)務(wù)處理模塊。從這些跡象看這個(gè)webapp基本沒有問題。但是后面glassfish卻莫名其妙的認(rèn)定，“this web application instance has been stopped already”，從而以ThreadDeath這種非常規(guī)的error來報(bào)錯(cuò)。
閱讀全文
摘要: 對比最近遇到的兩個(gè)事情，明顯感覺sun有力不從心或者心不在焉的感覺，oracle對sun收購的負(fù)面影響至少在開源社區(qū)方面是顯而易見的，個(gè)人甚至懷疑oracle正在逐漸放棄之前sun一直努力支撐的開源社區(qū)。
閱讀全文
摘要: 剛剛鄙視完sun，繼續(xù)performance tuning，結(jié)果又發(fā)現(xiàn)問題。
有點(diǎn)懷疑metro是不是根本就沒有做過性能測試，我們的測試場景，openESB下通過bepl調(diào)用4個(gè)我們稱為common service的webservice，目前大概做到1200個(gè)tps，算下來common service的webservice的tps大概是1200*4 = 5K附近，上面的問題就非常明顯，之前tps沒有上去前沒有這么嚴(yán)重。
可以參考我之前的一個(gè)blog， http://m.tkk7.com/aoxj/archive/2010/04/29/319706.html，在解決這里提到的http long connection 和 TIME_AIT的問題之前，我們的tps比較低，cpu壓不上去，當(dāng)時(shí)好像這個(gè)問題不明顯。后來搞定之后tps上來了才暴露出來。
考慮上一個(gè)blog中 == 比較無效導(dǎo)致cache失效的bug，我對metro的代碼質(zhì)量真是很沒有信息。按說這樣的大型項(xiàng)目，release之前怎么也要做做壓力測試，穩(wěn)定性測試之
閱讀全文
摘要: 依然是近期工作中發(fā)現(xiàn)的問題，真實(shí)案例，寫下來分享給大家。
總結(jié)：用 == 來比較非enum或者類型安全枚舉的對象實(shí)例，這種錯(cuò)誤一般只有初學(xué)者才犯，萬萬沒有想到，能在metro這樣級別的代碼中也能出現(xiàn)。無限感嘆啊，再次援引同事的評語作為本文的結(jié)束語：
sun的程序員也是程序員啊！
閱讀全文