问题
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
回答1:
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
来源：https://stackoverflow.com/questions/30674768/wildfly-8-2-jsf-sessionscoped-sometimes-wrong-data-returned