ejb
和ejb相關(guān)的內(nèi)容，包括weblogic
摘要: 當(dāng)時實際上，我們在檢查ThreadDeath的調(diào)用信息時，說明這個出現(xiàn)init()錯誤的filter還是被glassfish正常調(diào)用去執(zhí)行doFilter()方法，這里和j2ee API的要求是不符合的。有點奇怪的是，glassfish一向是以嚴(yán)格遵循j2ee規(guī)范而著稱，居然在這里一反常態(tài)。
而更令人 郁悶的是，glassfish在處理這個有filter初始化出現(xiàn)ServletException異常的webapp時的前后表現(xiàn)：首先這個 webapp的啟動沒有問題，狀態(tài)正常。filter也被認(rèn)為可以正常工作并加入了filter鏈。webapp中的功能正常，可以正常的接收請求并轉(zhuǎn)發(fā)給內(nèi)容業(yè)務(wù)處理模塊。從這些跡象看這個webapp基本沒有問題。但是后面glassfish卻莫名其妙的認(rèn)定，“this web application instance has been stopped already”，從而以ThreadDeath這種非常規(guī)的error來報錯。
閱讀全文
摘要: 在application server下，比如常見的weblogic，glassfish，jboss等，由于javaee規(guī)范的要求，一般不容許直接啟動線程。因此在常見的異步/并行任務(wù)執(zhí)行上，會遭遇到比普通javase程序更多的麻煩。
閱讀全文
摘要: 近期由于公司有意向在未來將目前的一個大型產(chǎn)品從weblogic移植到glassfish，因此提前學(xué)習(xí)glassfish以做好準(zhǔn)備。
首先從下載安裝開發(fā)，學(xué)習(xí)如何搭建glassfish的開發(fā)環(huán)境。
閱讀全文
摘要: 問題終于找到，簡單的說是因為java 系列化的效率低下，而ejb調(diào)用之間又大量使用系列化，因此造成極大的性能消耗，而且也影響到響應(yīng)時間。仔細(xì)分析了一下項目情況，呵呵，情況非常嚴(yán)重，系統(tǒng)架構(gòu)是按照三層來設(shè)計的，每個層都是ejb，調(diào)下一層都是通過遠(yuǎn)程接口，而且層之間可能還多個ejb的調(diào)用。
總結(jié)一下：
1. java serialize 非常慢
2. enable-call-by-reference可以有效避免這個開銷
因此，能enable-call-by-reference就盡量enable-call-by-reference。
閱讀全文
摘要: 接上篇，有興趣的朋友可以直接拿我的測試代碼自行測試,請自行修改諸如線程數(shù)，執(zhí)行時間，系列化的數(shù)據(jù)量大小等參數(shù)。如果想嘗試做thread dump，可以打開相關(guān)的兩個注釋，會更方便一些，代碼中都有相應(yīng)的注釋可供參考。
閱讀全文
摘要: 這是加入新公司后接手的第一個項目，使用weblogic9.2 + ejb2.0，壓力測試時發(fā)現(xiàn)速度非常慢，響應(yīng)時間很不理想，檢查日志發(fā)現(xiàn)，某些ejb相互調(diào)用時方法調(diào)用的時間非常長，高達(dá)300-500毫秒。非常夸張，因為兩個日志之間只是間隔了一個ejb調(diào)用。通過thread dump分析后發(fā)現(xiàn)有相當(dāng)多的線程在wait，檢查線程調(diào)用綻發(fā)現(xiàn)是在將參數(shù)進(jìn)行序列化時，線程試圖加鎖但是鎖被占用，因此處于等待狀態(tài)。考慮到 thread dump的這一瞬間，有多達(dá)30-50個線程都在同時試圖在同一個鎖上加鎖，很明顯這里的鎖競爭非常嚴(yán)重。
因此強(qiáng)烈懷疑是java的序列化機(jī)制導(dǎo)致的問題。
閱讀全文