[jboss-jira] [JBoss JIRA] (WFLY-4753) Wildfly 8.2 + JSF + SessionScoped : sometimes wrong data returned

[Olivier Texier (JIRA)]

     [ https://issues.jboss.org/browse/WFLY-4753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Olivier Texier closed WFLY-4753.
--------------------------------


The patch (Weld 2.12Final) seems to fix the problem.

Great answer, many thanks to you

> Wildfly 8.2 + JSF + SessionScoped : sometimes wrong data returned
> -----------------------------------------------------------------
>
>                 Key: WFLY-4753
>                 URL: https://issues.jboss.org/browse/WFLY-4753
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld
>    Affects Versions: 8.2.0.Final
>         Environment: wildfly 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)
>            Reporter: Olivier Texier
>            Assignee: Stuart Douglas
>
> 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



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)