Sticky Connections and JSESSIONID | Community
Skip to main content
broman__pl
broman__pl
Level 3
October 16, 2015
Solved

Sticky Connections and JSESSIONID

  • October 16, 2015
  • 5 replies
  • 4005 views

Hi,

I try to use HttpSession to store some user data. I created service that save data in session and read those data for user back, path to is is defined as sticky connection. And as long we use one CQ5.5 instance it works. But on multiple instances when user go to another page that is not defined as sticky connection user go to another instance and this instance change JSESSIONID and then I cannot read session data in my service.

Is ther any way to use sessions in multiple instance?

Thanks,

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by Pawan-Gupta

Hi,

To answer your questions

1. Above i talked about publish environment only. 

2. I mentioned to cluster App server means AEM similar to this http://dev.day.com/docs/en/crx/current/administering/cluster.html#Clustering Architecture so that all you publish server shared the same session data.

3. Dispatcher is deployed as module on your webserver to process server request with some extra feature but you can not assume it as server.

Thanks,

Pawan

5 replies

Pawan-Gupta
Pawan-Gupta
Level 8
October 16, 2015

Hi,

I think you have to do session clustering among servers so that the session data can be replicated to all the server. The new JSESSIONID is generating because the new server doesn't know any information about the user even though in request header is carrying the initial JSESSIONID.

Refer this link - http://dev.day.com/docs/en/cq/current/deploying/cluster.html

Thanks,

Pawan 

A
Anonymous
October 16, 2015

Are you talking about on an author instance or publish instance (which I assumed)?

If you are trying to maintain a session across multiple publish instances, typically you allow the Dispatcher module to handle it. The Dispatcher's configuration allows you to enabled sticky sessions. That means it will ensure that each user is routed to the same AEM instance until his/her session expires, ensuring that your JSESSIONID problem doesn't exist. Are you using the dispatcher for load balancing and sticky sessions?

Pawan-Gupta
Pawan-GuptaAccepted solution
Level 8
October 16, 2015

Hi,

To answer your questions

1. Above i talked about publish environment only. 

2. I mentioned to cluster App server means AEM similar to this http://dev.day.com/docs/en/crx/current/administering/cluster.html#Clustering Architecture so that all you publish server shared the same session data.

3. Dispatcher is deployed as module on your webserver to process server request with some extra feature but you can not assume it as server.

Thanks,

Pawan

broman__pl
broman__plAuthor
Level 3
October 16, 2015

Hi,

In my case sticky session works as long as user access to url that is configured as sticky but when user go to page that is not sticky it lost session.
So only solution with a sticky connection is to configure root path as sticky connection. Other solution may be synchronize session data among cluster nodes but in this case sticky connection is not necessary, so it looks like stickiness of connection cannot be used with http session.
Thanks

Pawan-Gupta
Pawan-Gupta
Level 8
October 16, 2015

Correct. If you have sticky session then you have to implement across otherwise you have to believe on servers clustering.

Terms & ConditionsAccessibility statement

Loading footer...