Wildfly 8.2 + JSF + SessionScoped:有时会返回错误的数据
Wildfly 8.2 + JSF + SessionScoped : sometimes wrong data returned
在我们的一个生产系统中,我们在 jboss 8.2 和最新的 JDK 7,centos 7 64 位,最新的 primefaces [=40 上遇到了一个非常奇怪的问题=]豆子。 (整个项目没有使用jsf注解,只使用CDI注解,避免潜在冲突)
在处理一个请求的某个时间点(我们不知道是什么触发了它)@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";
这里是处理请求时的日志行 "corrupted"(两个连续的请求)。注意登录值:
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 "broken" .当它被破坏时,如上图所示的数据不匹配是频繁但不系统的。
唯一的解决办法是重启 wildfly。
在 'corrupted' 状态下,只有一个用户有一个 HTTP 会话挂起(没有 HTTP 会话断开/连接),只需连续点击网页中的按钮即可观察到这种错误行为.关键是,我确信当服务器 'broken' 时,该错误可以仅由一个用户重现且没有负载。
提示:OurWeirdSessionScopedBean 是一个支持我们的 xhtml 页面的托管 Bean,并被注入 (CDI @Inject) 到处理中涉及的其他 CDI bean。
似乎注入到其他 CDI bean 中的 OurWeirdSessionScopedBean 的代理并不总是引用与 xhtml 页面的 backingBean 相同的数据。但它应该是同一个对象。 OurWeirdSessionScopedBean 被注解为@SessionScoped 和@Named。
有人遇到过这样的行为吗?有人有解释/解决方案或解决方法吗?
非常感谢
我们似乎确实遇到了位于 Weld 中的 Wildfly 8.2 错误。有关详细信息,请参阅此 jira:https://issues.jboss.org/browse/WFLY-4753
解决办法是用这个补丁给 Wildfly 打补丁:http://sourceforge.net/projects/jboss/files/Weld/2.2.12.Final
谢谢大家
在我们的一个生产系统中,我们在 jboss 8.2 和最新的 JDK 7,centos 7 64 位,最新的 primefaces [=40 上遇到了一个非常奇怪的问题=]豆子。 (整个项目没有使用jsf注解,只使用CDI注解,避免潜在冲突)
在处理一个请求的某个时间点(我们不知道是什么触发了它)@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";
这里是处理请求时的日志行 "corrupted"(两个连续的请求)。注意登录值:
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 "broken" .当它被破坏时,如上图所示的数据不匹配是频繁但不系统的。
唯一的解决办法是重启 wildfly。
在 'corrupted' 状态下,只有一个用户有一个 HTTP 会话挂起(没有 HTTP 会话断开/连接),只需连续点击网页中的按钮即可观察到这种错误行为.关键是,我确信当服务器 'broken' 时,该错误可以仅由一个用户重现且没有负载。
提示:OurWeirdSessionScopedBean 是一个支持我们的 xhtml 页面的托管 Bean,并被注入 (CDI @Inject) 到处理中涉及的其他 CDI bean。
似乎注入到其他 CDI bean 中的 OurWeirdSessionScopedBean 的代理并不总是引用与 xhtml 页面的 backingBean 相同的数据。但它应该是同一个对象。 OurWeirdSessionScopedBean 被注解为@SessionScoped 和@Named。
有人遇到过这样的行为吗?有人有解释/解决方案或解决方法吗?
非常感谢
我们似乎确实遇到了位于 Weld 中的 Wildfly 8.2 错误。有关详细信息,请参阅此 jira:https://issues.jboss.org/browse/WFLY-4753
解决办法是用这个补丁给 Wildfly 打补丁:http://sourceforge.net/projects/jboss/files/Weld/2.2.12.Final
谢谢大家