]
Gabriel Lavoie commented on WFLY-6489:
--------------------------------------
When attempting to diagnose the issue, I found out that response.sendRedirect() flushes
immediately the response that includes the Location header. This causes the browser to hit
immediately the new URL before the previous call had the chance to complete. This can
cause issues when filters are getting unstacked and they need to set session data (in the
existing session) before the redirection occurs.
A good example of this is the Spring SecurityContextPersistenceFilter that will persist
the security context into the session only when the servlet request is completed and the
filters are being unstacked. The next call may not yet see the security context.
I verified the behavior with EAP 6.1, Tomcat 8 and Glassfish 4 and they flush the headers
only when everything related to the request has been processed.
Please tell me if I should open a new bug ticket for this other change of behavior.
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: 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.