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