Terracotta Discussion Forums (LEGACY READ-ONLY ARCHIVE)

Hi,

I'm using Apache 2.2 to load balance a cluster of Tomcats 5.5.20 instances.

Apache wants a jvm route to show up in the session cookie at the end, separated from the rest of the session by a '.'.

Configuring Tomcat to include a jvmRoute causes it to stick that at the end of the session, just how Apache wants it.

Unfortunately using Terracotta Sessions causes that not to work -- TC seems to want to pretend it's WebLogic or something, and sticks !0 or something equivalent on the session, blowing away my jvmRoute.

I think it would be nice for TC to respect the jvmRoute when Tomcat is so configured. Is it possible to make it do so?

Also, how is the value after the '!' determined? I could imagine modifying Apache to use '!' instead of '.' for the delimiter, but that's kind of a pain, and even if I did that, I don't know how to come up with a stable mapping between one of my known Tomcat instances, and the value that shows up there -- in Apache my understanding is that you have to specify the mapping between jvmRoute and balancer instance (even though in theory it could figure that out itself, so maybe I'm wrong).

Thanks,
Eric

A bit more searching and I found the Sessions Architecture document, which made me confident that adding something like this to my java command line (when starting up tomcat) would sort this issue for me:

-Dcom.terracotta.session.serverid=.${jvm.route}

...that is, putting a '.' in the name I give TC.

But doing that seems to be ignored by TC ... when I see this system property is set (copied and pasted from JVM output):

com.terracotta.session.serverid=.BLAH

I still get a session cookie back like:

Set-Cookie: JSESSIONID=67BA8001DE61BE2EDF25!0; Path=/

So I'm wondering, what do I have to do to get TC to obey the fact that I'm setting that system property?

Thanks, Eric

Your analysis is correct and load balancing components that depend on specific cookie formats are bound to break (or require adjustment) with terracotta sessions.

It sounds like we have some old documentation out there. To adjust the serverid component, create a file called "tc.properties" and place it in the common/lib folder of the terracotta distribution. In that properties file, add this line:

Code:

session.serverid=.myJvmRoute

I'll throw something in JIRA about the documentation issue. If you happen to know the URL, posting it here would help.

This is the url to that document: http://www.terracotta.org/confluence/display/devdocs/Sessions+Architecture

I'm trying to think of how to get the user-facing stuff in this document into the regular documentation. In the meantime, Alex V. should probably update this to the current values.

Tim Eck wrote:

Your analysis is correct and load balancing components that depend on specific cookie formats are bound to break (or require adjustment) with terracotta sessions.

It sounds like we have some old documentation out there. To adjust the serverid component, create a file called "tc.properties" and place it in the common/lib folder of the terracotta distribution. In that properties file, add this line:

Code:
session.serverid=.myJvmRoute
I'll throw something in JIRA about the documentation issue. If you happen to know the URL, posting it here would help.

If you are using Terracotta Version 2.3 and higher, the distribution package structure has changed slightly.

You will put the tc.properties in $TC_INSTALL_DIR/lib instead of $TC_INSTALL_DIR/common/lib - there is no common directory any more.

Regards,
Kunal Bhasin.

I'm trying to run multiple instances of tomcat per physical machine ... do I really need to have a separate TC installation for each tomcat instance? That seems odd.

You should typically only need one Terracotta installation per physical machine. The goal is to make the Terracotta libraries located in the lib directory of the installation available to the Java Runtime Environment. You do not need a separate installation per VM if they are on the same physical machine (as long as each VM has access to the installation libraries).

If you wish to use a different jvm route for each instance, you can do so by passing the system property -Dcom.tc.session.serverid to each VM instance instead of setting it in the tc.properties file.

Regards,
Kunal Bhasin.

The documentation says I can pass -Dcom.terracotta.session.serverid=..., but that doesn't work. You are saying I can pass -Dcom.tc.session.serverid=..., but that doesn't work either.

When I pass -Dcom.tc.session.serverid=.0, I see:

Set-Cookie: JSESSIONID=CA0480006A70B106739D!0; Path=/

When I pass -Dcom.terracotta.session.serverid=.0, I see:

Set-Cookie: JSESSIONID=F9718000119142C113F9!0; Path=/

I'm really happy passing -D[something] per JVM to set the serverid, but I can't find a value that actually works, and the code didn't help much.

If there is a system property I can set, what IS that system property, if not com.terracotta.session.serverid or com.tc.session.serverid?

Thanks,
Eric

The problem with getting the system property to work is described here:

https://jira.terracotta.org/jira/browse/CDV-228

I've attached a version of tc.properties with the session.serverid property uncommented. Place it in the lib directory and you should be able to override properly.

Just to be clear:

(1) you need to work around the aforementioned JIRA issue by having a tc.properties in the lib directory that includes the session.serverid key.

(2) you need to override that value by passing -Dcom.tc.session.serverid=.N as a system property to your web container.

I've validated that it works in the 2.3-stable release.

I get it ... in fact I've made that exact same kind of configuration bug myself.

Thanks for your help, that works.