Wildfly 8.2+；JSF+；会话范围：有时返回错误的数据

在我们的一个生产系统中，我们在jboss 8.2和最新的JDK 7、centos 7 64位以及javax.enterprise.context.SessionScoped bean上的最新primefaces中遇到了一个非常奇怪的问题。（整个项目中不使用jsf注释，仅使用CDI注释以避免潜在冲突）

在处理一个请求的过程中，@SessionScoped bean在某个时间点（我们不知道是什么触发了它）给出了相互矛盾的信息。然而，处理总是只发生在一个会话和一个线程中

以下是正常处理请求（此处为两个连续请求）时的日志行（简化示例）：

以下是请求处理“损坏”（两个连续请求）时的日志行。注意登录值：

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“坏了”。当它被破坏时，如上所示的数据不匹配是频繁的，但不是系统性的

唯一的解决办法是重新启动wildfly

在“已损坏”状态下，只有一个用户的http会话处于挂起状态（没有http会话断开/连接），只需连续单击网页中的按钮，就可以观察到此错误行为。关键是，我可以肯定，当服务器“坏了”时，只需一个用户就可以在没有负载的情况下复制错误

提示：OurWeirdSessionScopedBean是支持xhtml页面的managedBean，它被注入（CDI@Inject）到处理过程中涉及的其他CDIBean中

似乎在其他CDIBean中注入的我们的WeirdSessionScopedBean的代理并不总是引用与xhtml页面的backingBean相同的数据。但它应该是同一个对象。OurWeirdSessionScopedBean被注释为@SessionScoped和@Named

有人遇到过这样的行为吗？有人有解释/解决方案或变通方法吗

---

非常感谢

看来我们确实遇到了Wildfly 8.2 bug，它位于Weld中。有关更多信息，请参阅此jira：

修复方法是使用此修补程序修补Wildfly：

---

谢谢大家

说清楚，您是说注入了错误的会话bean？会话ID是否实际更改。e、 g.使用

（（HttpSession）FacesContext.getCurrentInstance（）.getExternalContext（）.getSession（false））.getId（））记录它。

。给定请求的会话id不会更改。我们没有记录会话id（我在这里输入了它）。对于req 1的每个日志行，会话Id与req 1一致，并且不会更改。其他请求也一样。但是会话作用域bean返回的数据不一致，并且由于任何原因而改变。我们昨天遇到了这个问题，我很高兴，我在这里找到了你的帖子。我们正在调查这是否解决了我们昨天的经历。。。祝你好运。很难复制。。。

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";