在我们的生产系统中，我们遇到了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