Wildfly 8.2 + JSF + SessionScoped：有时返回错误的数据 [英] Wildfly 8.2 + JSF + SessionScoped : sometimes wrong data returned

问题描述

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

在某些时候（我们不知道是什么触发了） @SessionScoped bean对一个请求的处理给出了矛盾的信息。然而，处理始终只在一个会话和一个线程中进行。

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

  15:00:00：线程1-请求1-OurWeirdSessionScopedBean.process.step1：登录名： UserA； 
 15:00:00：线程1-请求1-OurWeirdSessionScopedBean.process.step2：登录： UserA; 
 15:00:00：线程1-请求1-OurWeirdSessionScopedBean.process.step3：登录： UserA; 
 15:00:00：线程1-请求1-OurWeirdSessionScopedBean.process.step4：登录： UserA; 
 15:00:00：线程1-请求1-OurWeirdSessionScopedBean.process.step5：登录： UserA; 
 15:00:01：线程1-请求1-OurWeirdSessionScopedBean.process.step6：登录： UserA; 
 15:00:01：线程1-请求1-OurWeirdSessionScopedBean.process.step7：登录： UserA; 
 
 15:00:04：线程2-请求2-OurWeirdSessionScopedBean.process.step1：登录： UserB； 
 15:00:04：线程2-请求2-OurWeirdSessionScopedBean.process.step2：登录： UserB； 
 15:00:04：线程2-请求2-OurWeirdSessionScopedBean.process.step3：登录名： UserB； 
 15:00:04：线程2-请求2-OurWeirdSessionScopedBean.process.step4：登录名： UserB； 
 15:00:04：线程2-请求2-OurWeirdSessionScopedBean.process.step5：登录名： UserB； 
 15:00:04：线程2-请求2-OurWeirdSessionScopedBean.process.step6：login： UserB； 
 15:00:04：线程2-请求2-OurWeirdSessionScopedBean.process.step7：登录名： UserB； 
  

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

  16:00:00：线程1-请求1-OurWeirdSessionScopedBean.process.step1：login： UserA； 
 16:00:00：线程1-请求1-OurWeirdSessionScopedBean.process.step2：登录： UserB; 
 16:00:00：线程1-请求1-OurWeirdSessionScopedBean.process.step3：登录： UserB; 
 16:00:00：线程1-请求1-OurWeirdSessionScopedBean.process.step4：登录： UserA; 
 16:00:00：线程1-请求1-OurWeirdSessionScopedBean.process.step5：登录： UserB; 
 16:00:01：线程1-请求1-OurWeirdSessionScopedBean.process.step6：登录： UserB; 
 16:00:01：线程1-请求1-OurWeirdSessionScopedBean.process.step7：登录： UserA; 
 
 16:00:04：线程2-请求2-OurWeirdSessionScopedBean.process.step1：登录： UserB； 
 16:00:04：线程2-请求2-OurWeirdSessionScopedBean.process.step2：登录名： UserX； 
 16:00:04：线程2-请求2-OurWeirdSessionScopedBean.process.step3：login： UserX； 
 16:00:04：线程2-请求2-OurWeirdSessionScopedBean.process.step4：登录名： UserB； 
 16:00:04：线程2-请求2-OurWeirdSessionScopedBean.process.step5：login： UserX； 
 16:00:04：线程2-请求2-OurWeirdSessionScopedBean.process.step6：login： UserX； 
 16:00:04：线程2-请求2-OurWeirdSessionScopedBean.process.step7：登录名： UserB； 
  

长时间（通常为5-10小时）一切正常，然后会发生一些事情（时间/线程耗尽/运气不佳/ ....？不知道），然后webapp被破坏。当损坏时，上面说明的数据失配是经常发生的，但不是系统性的。

唯一的解决方案是重新启动Wildfly。

在已损坏状态下，只有一名正在处理HTTP会话的用户（没有HTTP会话断开/连接），只有连续单击网页上的按钮，才能观察到这种错误行为。关键是，我很肯定当服务器损坏时，该错误只能在一个用户且没有负载的情况下重现。

提示：OurWeirdSessionScopedBean是managedBean的后盾

似乎是否将OurWeirdSessionScopedBean的代理注入了其他CDI Bean中。

并不总是引用与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

谢谢大家

In one of our systems in production we encounter a very weird problem in jboss 8.2 and latest JDK 7, centos 7 64 bits, latest primefaces on javax.enterprise.context.SessionScoped beans. (No jsf annotations are used in the whole project, only CDI annotation to avoid potential conflicts)

At some point in time (we don't know what triggers it) during the processing of one request the @SessionScoped bean give contradictory informations. Yet the processing occurs always in only one session and one Thread.

Here are log lines (simplified example) when the processing of the requests is normal (here two successive requests):

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

Here are log lines when the processing of the request is "corrupted" (two successive requests). Watch for login value :

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

For a long time (generally 5-10 hour) all is ok, then something occurs (time / thread exhaustion / bad luck / .... ? no idea) and then the webapp is "broken". When it is broken, the data mismatch as illustrated above is frequent but not systematic.

The only solution is to reboot wildfly.

In the 'corrupted' state, this buggy behavior can be observed with only one user with an http session pending (no http session disconnect / connect), with only successive clicks on a button in the web page). The point is that I am positive that when the server is 'broken' the bug can be reproduced with only one user and no load.

Hint : OurWeirdSessionScopedBean is a managedBean backing our xhtml page, and is injected (CDI @Inject) in other CDI beans involved in the processing.

It seems like if the proxy for OurWeirdSessionScopedBean injected in the other CDI beans doesn't always reference the same data that the backingBean of the xhtml page. But it should be the same object. OurWeirdSessionScopedBean is annotated as @SessionScoped and @Named.

Did anybody encounter such a behaviour ? Does somebody have an explanation / a solution or a workaround ?

Many thanks

解决方案

It seems we did encounter a Wildfly 8.2 bug, located in Weld. See this jira for more information : https://issues.jboss.org/browse/WFLY-4753

The fix has been to patch Wildfly with this patch : http://sourceforge.net/projects/jboss/files/Weld/2.2.12.Final

Thank you all

这篇关于Wildfly 8.2 + JSF + SessionScoped：有时返回错误的数据的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！