Terracotta Discussion Forums (LEGACY READ-ONLY ARCHIVE)

We recently switched to using distributed Terracotta Sessions across our Tomcat grid and we have ran into a problem that we are having a very difficult time tracking down and we think it may be related to a Terracotta issue.

Apparently on rare occasions Tomcat will produce multiple JSESSIONID for the same web application. (Don't ask me how there are many Google results try googling for "multiple JSESSIONID cookies" Tomcat) Anyway, it appears that when this happens Tomcat will typically process both of the JSESSIONID and everything works fine. However, if we are using Terracotta to handle our session then it appears that it may only be looking at the first one, not finding it it resets the session which creates a new one and the whole thing starts over.

So in essence you can either never retrieve what you originally stored in the second JSESSIONID that never gets overwritten but Terracotta does not use it for lookup. Or you store something in a JSESSIONID that is immediately reset and when you come back to the Terracotta cluster it is stored but you cannot access it because the JSESSIONID was reset.

This is an unusual problem, has ANYONE seen this before?

Thanks in advance.

Keith

Hi Keith,

Can you provide some more information to find the root cause here:-

1. How many tomcat servers are there in the cluster?
2. Are you using a sticky load balancing policy?
3. Please provide logs with jsessionid details?
(To enable session debugging create tc.properties file in
$TC_INSTALL_DIR/lib folder and add "session.debug.sessions = true;" property. )
4. Are you using single sign on?

Please let us know more details and if you can reproduce the issue, please provide steps to reproduce.

Thanks,
Rohit Reja
Terracotta Engineer.

Hi Keith,

Please provide the version of terracotta and tomcat that you are
using.

Thanks,
Rohit Reja
Terracotta Engineer

1. Six Tomcat (version 6.0.13) servers are in the cluster
2. We have two redundant hardware load balancers that are using a sticky load balancer policy by keying off jvmRoute that is a property of the Engine.
3. You want the Terracotta logs or the Tomcat logs? ( I will restart the Terracotta severs with the sessions debugging turned on and recreate the problem.)
4. We have 3 web applications in the same Tomcat instance. Two of the web applications use SSO the third does not. The application that does not use SSO is the one we are having issues with. It may be that the problem occurs in the other two web applications but we have just not noticed it yet.
5. We have two Terracotta 2.6.2 servers.

Steps
1. Access web application by linking to it from another site. (Your JSESSIONID should be set.)
2. Store something in the session.
3. Navigate away or hit the back button.
4. Link back to the web app again and notice that you cannot retrieve what you have stored. (If you are dumping the request you will notice that there are two JSESSIONID one stays constant and the other continues to change on each refresh of the page.)

This is definitely a Terracotta issue, as now confirmed.

Basically I made the load balancer always go to the same application server and then I tried it with and without Terracotta running. Without Terracotta running everything works, with Terracotta it all goes to hell.

I don't know if this is a symptom of the problem or this is a side effect but the JSESSIONID that are generated without Terracotta running are almost twice the length 36AD6A27AE592E4899249A85DD3BE04D.app1 versus B7B9800066834C00F96A.app1.

So I guess the question is WHY is Terracotta generating a new JSESSIONID every time the web application is called instead of using the one that is generated the first time the web application is executed by the client.

Anyone on what this might be?

Thanks in advance.

Well after looking into the default tc.properties file that is contained within the tc.jar I see why the length is 20 characters long as well as all of the other default session parameters.

I just don't see anything that might solve my problem of every request to the web application receiving a new JSESSIONID.

Anyone have ANY ideas here. Really I mean it.

Sorry I don't have any idea but I remember a somewhat familiar post. See if it heps http://forums.terracotta.org/forums/posts/list/686.page

Thanks for the link, and although similar I am using hardware load balancers and the other issues was a problem with mod_jk which is when you use Apache as the load balancer.

Still don't know why but the JSESSIONID continues to be reset upon each access to the domain.

Any other ideas?

kbottner wrote:

Well after looking into the default tc.properties file that is contained within the tc.jar I see why the length is 20 characters long as well as all of the other default session parameters.

I just don't see anything that might solve my problem of every request to the web application receiving a new JSESSIONID.

Anyone have ANY ideas here. Really I mean it.

Hey, sorry to interrupt on this thread. I can't really help you with the technical bit, but I would just like to make sure you are aware that we provide enterprise support for just this kind of thing. We have developer support, consulting and training as well as enterprise subscription with enterprise support, sla's and all the stuff you'd expect from commercial software.

If you really need an answer fast, this is how you get it.

http://www.terracottatech.com/confluence/display/comsite/Enterprise+Offerings

All right here is the solution for the next guy that has this problem along with some other nuggets.

1. jvmRoute and the tc.properties session.serverid does the same thing. One or both needs to be set. (This is what the load balancers will key off of to make sure the session gets routed to the previous server.)
2. YOU NEED TO SET the session.cookie.name within the tc.properties. The default is JSESSIONID, but set it to something else FOOCOOKIE or something.

Once we changed the session.cookie.name (and updated our load balancers to use the new cookie name) everything started working and we were not getting the JSESSIONID reset on each refresh.

I am not sure what is causing the problem under the hood but setting the session.cookie.name in tc.properties causes something to happen under the hood that fixes our issue.

I hope this helps somebody else as this was taken 5 years off of my life trying to figure this out.

Also props to CDV-297, CDV-30 and CDV-29, bug reports for Terracotta which all helped us to diagnosis. Thanks for sharing.