在我們的生產系統中，我們遇到了jboss 8.2和最新的JDK 7，centos 7 64位以及javax.enterprise.context上的最新primefaces中的一個非常奇怪的問題。 SessionScoped beans。 （在整個項目中沒有使用jsf註釋，只有CDI註釋才能避免潛在衝突）Wildfly 8.2 + JSF + SessionScoped：有時會返回錯誤的數據
在某個時間點（我們不知道是什麼觸發它）在處理一個請求期間@SessionScoped bean給出了矛盾信息。然而，處理總是隻發生在一個會話和一個線程中。
下面是日誌行（簡化的例子），當請求的處理是正常（這裏兩個連續請求）：
15:00:00 : thread 1 - req 1 - OurWeirdSessionScopedBean.process.step1 : login : "UserA";
15:00:00 : thread 1 - req 1 - OurWeirdSessionScopedBean.process.step2 : login : "UserA";
15:00:00 : thread 1 - req 1 - OurWeirdSessionScopedBean.process.step3 : login : "UserA";
15:00:00 : thread 1 - req 1 - OurWeirdSessionScopedBean.process.step4 : login : "UserA";
15:00:00 : thread 1 - req 1 - OurWeirdSessionScopedBean.process.step5 : login : "UserA";
15:00:01 : thread 1 - req 1 - OurWeirdSessionScopedBean.process.step6 : login : "UserA";
15:00:01 : thread 1 - req 1 - OurWeirdSessionScopedBean.process.step7 : login : "UserA";
15:00:04 : thread 2 - req 2 - OurWeirdSessionScopedBean.process.step1 : login : "UserB";
15:00:04 : thread 2 - req 2 - OurWeirdSessionScopedBean.process.step2 : login : "UserB";
15:00:04 : thread 2 - req 2 - OurWeirdSessionScopedBean.process.step3 : login : "UserB";
15:00:04 : thread 2 - req 2 - OurWeirdSessionScopedBean.process.step4 : login : "UserB";
15:00:04 : thread 2 - req 2 - OurWeirdSessionScopedBean.process.step5 : login : "UserB";
15:00:04 : thread 2 - req 2 - OurWeirdSessionScopedBean.process.step6 : login : "UserB";
15:00:04 : thread 2 - req 2 - OurWeirdSessionScopedBean.process.step7 : login : "UserB";
下面是當請求的處理「損壞」日誌線（雙連續的請求）。留意登錄值：
16:00:00 : thread 1 - req 1 - OurWeirdSessionScopedBean.process.step1 : login : "UserA";
16:00:00 : thread 1 - req 1 - OurWeirdSessionScopedBean.process.step2 : login : "UserB";
16:00:00 : thread 1 - req 1 - OurWeirdSessionScopedBean.process.step3 : login : "UserB";
16:00:00 : thread 1 - req 1 - OurWeirdSessionScopedBean.process.step4 : login : "UserA";
16:00:00 : thread 1 - req 1 - OurWeirdSessionScopedBean.process.step5 : login : "UserB";
16:00:01 : thread 1 - req 1 - OurWeirdSessionScopedBean.process.step6 : login : "UserB";
16:00:01 : thread 1 - req 1 - OurWeirdSessionScopedBean.process.step7 : login : "UserA";
16:00:04 : thread 2 - req 2 - OurWeirdSessionScopedBean.process.step1 : login : "UserB";
16:00:04 : thread 2 - req 2 - OurWeirdSessionScopedBean.process.step2 : login : "UserX";
16:00:04 : thread 2 - req 2 - OurWeirdSessionScopedBean.process.step3 : login : "UserX";
16:00:04 : thread 2 - req 2 - OurWeirdSessionScopedBean.process.step4 : login : "UserB";
16:00:04 : thread 2 - req 2 - OurWeirdSessionScopedBean.process.step5 : login : "UserX";
16:00:04 : thread 2 - req 2 - OurWeirdSessionScopedBean.process.step6 : login : "UserX";
16:00:04 : thread 2 - req 2 - OurWeirdSessionScopedBean.process.step7 : login : "UserB";
在很長一段時間（一般5-10小時）一切正常，然後發生的東西（？時間/線程耗盡/厄運/ ....不知道），然後webapp是「破」的。當它被破壞時，如上所述的數據不匹配是頻繁但不繫統的。
唯一的解決辦法是重啓野蠅。
在'已損壞'狀態下，只有一個用戶掛起http會話（沒有http會話斷開/連接），並且只有連續的網頁按鈕點擊，才能觀察到這種錯誤行爲。關鍵是，我確信，當服務器「損壞」時，只有一名用戶和沒有負載的情況下才能重現該錯誤。
提示：OurWeirdSessionScopedBean是託管我們的xhtml頁面的managedBean，並且在涉及處理的其他CDI bean中注入（CDI @Inject）。
看來，如果在其他CDI bean中注入OurWeirdSessionScopedBean的代理並不總是引用與xhtml頁面的backingBean相同的數據。但它應該是同一個對象。 OurWeirdSessionScopedBean註釋爲@SessionScoped和@Named。
有沒有人遇到過這樣的行爲？有人有解釋/解決方案或解決方法嗎？
非常感謝
要清楚，你說了錯誤的會話bean被注入？會話ID實際上是否改變。例如用（（HttpSession）FacesContext.getCurrentInstance（）。getExternalContext（）。getSession（false））.getId（））'記錄它。 – DavidS
對於給定的請求，會話ID不會更改。我們做了日誌會話ID（我在這裏忽略了它）。對於需求1的每個日誌行，會話Id與需求1一致，且不會更改。其他請求也一樣。 但會話作用域bean返回的數據不一致，並且因任何原因而發生更改。 – NodeNoob