[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:comment-tabpanel&focusedCommentId=13187689#comment-13187689 ] 

Gabriel Lavoie commented on WFLY-6489:
--------------------------------------

Hi Paul,
At this time our app has business transactions that access the session in a single thread of the JVM that may take longer than 15 seconds (realizing this is configurable, but the problem remains the same just with longer waits) resulting in blocking and eventual timeout of other business transactions happening concurrently with that session. 

We rely heavily on the developer being responsible for the providing thread safe access to the attributes in the session. Setting the container to pessimistic (even if we can improve/stabilize concurrent access cases in the app) provides a very large lock on our apps concurrency and will appear like a performance hit. SRV.7.7.1 (servlet-3.1 https://java.net/downloads/servlet-spec/Final/servlet-3_1-final.pdf) allows such concurrent access on the session with a synchronization on the session and not on the request.

SRV.7.7.2 also mentions that all request that are part of a session should hit the same JVM (we use sticky session) and that the developer should expect no additional concurrency issues beyond those encountered in a non-distributed container. The issue described here occurs only while hitting a single JVM with <distributable /> sessions. 

I'm attaching an updated sample webapp that can reproduce the issue with every session creation (/issue/sessionissuedisplayservlet), not just the first time after startup. In that sample, we think that the JSESSIONID should never be returned to the browser with the session not accessible on a separate request on the same node.

After digging a bit in the WildFly code, we found a possible workaround to force the commit/replication of a new session by calling updateSessionAccessTime(), but it has the side effect of blocking the replication of any session attribute updated after this forced replication until the session is modified by a future request. Note that sendRedirect() has this same bad side effects if any session attribute is updated after the call as it also immediately updates the session access time.

Regards


> 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)