[jboss-jira] [JBoss JIRA] (WFLY-4414) Non Standard SESSIONID not clustered

[Robert Smith (JIRA)]

    [ https://issues.jboss.org/browse/WFLY-4414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13048559#comment-13048559 ] 

Robert Smith commented on WFLY-4414:
------------------------------------

We have not configured the custom sticky session.

balancer: [1] Name: other-server-group Sticky: 1 [JSESSIONID]/[jsessionid] remove: 0 force: 0 Timeout: 0 maxAttempts: 1

node: [2:2],Balancer: other-server-group,JVMRoute:<urn>:server_2,LBGroup: [],Host: <ip>,Port: 8153,Type: ajp,flushpackets: 0,flushwait: 10,ping: 10,smax: 1,ttl: 60,timeout: 0
node: [3:3],Balancer: other-server-group,JVMRoute: <urn>:server_1,LBGroup: [],Host: <ip>,Port: 8153,Type: ajp,flushpackets: 0,flushwait: 10,ping: 10,smax: 1,ttl: 60,timeout: 0

host: 3 [localhost] vhost: 1 node: 2
host: 4 [default-host] vhost: 1 node: 2
host: 5 [localhost] vhost: 1 node: 3
host: 6 [default-host] vhost: 1 node: 3

The backend services to the webapplication are using Serializable objects to store in the session. One such object (an auth object) is compared on every incoming request after originally being set in the initial request via session.setAttribute. Subsequent requests are doing a round robin to the 2 nodes in our server group. When it bounces to the other node, we receive a new session id back and the object is null which has led me to the conclusion that replication is not happening. We have done similar tests with JSESSIONID (bringing the sticky node down), and the session is replicated.

> Non Standard SESSIONID not clustered
> ------------------------------------
>
>                 Key: WFLY-4414
>                 URL: https://issues.jboss.org/browse/WFLY-4414
>             Project: WildFly
>          Issue Type: Feature Request
>            Reporter: Robert Smith
>            Assignee: Jason Greene
>
> We are using Wildfly 8.1.0-Final in domain mode with mod-cluster.
> We use a non-standard session id in a web application as follows:
> ...
>        <distributable />
> 	<session-config>
> 		<cookie-config> 
> 		    <name>VSOPSESSIONID</name>
> 		</cookie-config>
> 	</session-config>
> ...
> During testing of this we had our sticky set to JSESSIONID which caused requests to be forwarded to our 2 nodes alternatively.
> In our 1st request we do:
> request.getSession().setAttribute(KEY, value)
> In our 2nd request we do:
> request.getSession.getAttribute(KEY)
> The second request always returns null.
> When we remove the custom session id, the session data is avaliable.



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)