[
https://issues.jboss.org/browse/WFLY-4414?page=com.atlassian.jira.plugin....
]
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)