[jboss-jira] [JBoss JIRA] (WFLY-6489) Distributable session may not exist after redirect to same node with optimistic locking.

[Gabriel Lavoie (JIRA)]

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

Gabriel Lavoie updated WFLY-6489:
---------------------------------
    Attachment: wfly-6489-showcase.zip


Attaching updated sample app to show the issue (wfly-6489-showcase.zip)

> Distributable session may not exist after redirect to same node with optimistic locking.
> ----------------------------------------------------------------------------------------
>
>                 Key: WFLY-6489
>                 URL: https://issues.jboss.org/browse/WFLY-6489
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 8.2.1.Final, 10.0.0.Final, 10.1.0.Final
>            Reporter: Gabriel Lavoie
>            Assignee: Paul Ferraro
>            Priority: Critical
>         Attachments: wfly-6489-showcase.zip, wildfly-10-session-issue.zip
>
>
> I'm currently working on porting an application running on EAP 6.1 to WildFly 10 and am encountering multiple session/authentication issues with clustering enabled. Our login flow currently starts from a servlet that accepts the credentials, creates the session, then redirect to the welcome page. 
> The first time we execute this flow after the startup of a node, the welcome page can't see at all the session created previously.
> - request.getSession() creates yet another session and a new session cookie is returned.
> - request.getSession(false) returns "null"
> On the second attempt, the flow works as expected.
> The issue can be reproduced on both a single node or a two nodes cluster, as long as <distributable /> is enabled in web.xml. 
> We are currently using the master build https://ci.jboss.org/hudson/job/WildFly-latest-master/2244/, but the problem has been noticed on 10.0.0-Final and also 8.2.1-Final.
> I attached a sample web application that I used to reproduce the issue. Our standalone.xml is also included with the clustering configuration we've been using for the web/session cache.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)