Terracotta Discussion Forums

I'm setting the serverid for each of the Tomcats in cluster:

-Dcom.tc.session.serverid=tomcat2

What I'm seeing when I look at the JSESSIONID cookie is that I am jumping around from server to server instead of staying on the initial server

D0408005D0BF854E2151.tomcat2
D0408005D0BF854E2151.tomcat3
D0408005D0BF854E2151.tomcat2
D0408005D0BF854E2151.tomcat2
D0408005D0BF854E2151.tomcat3
D0408005D0BF854E2151.tomcat3

So, the session id (D0408005D0BF854E2151) is fine, but I'm jumping from instance to instance randomly. I don't mind that this is happening, but I figured I would always go back to the same server since is was implementing the jvmRoute. Is this the expected behaviour?

Thanks,

Darin

Apache 2.2.6 with mod_jk 1.2.25
Tomcat 5.5.25
Terracotta 2.5.0, as of 20071210-171202 (Revision 6472 by cruise@WXPMO0 from 2.5)

workers.properties:
worker.list=terra-router

worker.tomcat2.port=8209
worker.tomcat2.host=localhost
worker.tomcat2.type=ajp13
worker.tomcat2.lbfactor=1

worker.tomcat3.port=8309
worker.tomcat3.host=localhost
worker.tomcat3.type=ajp13
worker.tomcat3.lbfactor=1

worker.terra-router.type=lb
worker.terra-router.balance_workers=tomcat2,tomcat3
worker.terra-router.sticky_session=1

It sure would be a great Christmas present if someone weighed in on this...

Thanks,

Darin

Whoops. Sorry about that. We have this kind of dumb manual process for handling forum threads that isn't really very accurate nor sustainable. We'll be fixing that up soon, I hope. In the meantime, I'll see if I can drum up some help on this...

--Orion

Hi Darin,

Merry Christmas!

I am sure you know this but I am just going to clarify for other folks as well: Terracotta is a clustering technology that will ensure session fail-over and replication if the session hops from one node to another in a cluster, but Terracotta does not provide any load-balancing.

Now I see that you are configuring apache modjk to get the load-balancing.

1. Are you sure you are hitting the web-server on port 80 and not the Tomcat instance directly on port 8080?

2. Is the httpd configuration correct?

3. Are the ips configured properly? One of the issues I remember is that extra white-spaces after the IP addresses in config.xml seem to not work.

4. Can you try the configuration without terracotta and see if the sticky-loadbalancing works?

Here is an example:

This example uses an Apache HTTP server with the mod jk module, and three Tomcat instances load balanced with sticky sessions. Note that the example does not cover any access control or authorization. It is recommended that you restrict access to the mod jk status Worker.

The following is an httpd.conf snippet that sets up mod jk:

Code:

 # Load the mod_jk module. You would obviously use the 
 # path to your own httpd installation. 
 
 LoadModule jk_module /Volumes/Files/asf/httpd-r415210w/modules/mod_jk.so 
 
 # Mount your web applications. Any examples that you want 
 # to test.
  
 JKMount /servlets-examples/* loadbalancer 
 JKMount /*.jsp loadbalancer 
 
 # The mod_jk Manager application. Please implement appropriate 
 # access control on production systems. 
 
 JkMount /jkmanager/* jkstatus 
 
 # Log mod_jk activity. You probably want a less verbose log level 
 
 JKLogFile logs/jk_log 
 JKLogLevel debug 
 
 # The JKWorkerProperty directive is new as of mod_jk 1.2.7. It allows 
 # you to specify mod_jk worker configuration directives in httpd.conf 
 # instead of a separate workers.properties file 
 
 JKWorkerProperty worker.list=loadbalancer,jkstatus 
 
 # Define three Tomcat instance workers 
 
 JKWorkerProperty worker.tc1.port=15109 
 JKWorkerProperty worker.tc1.host=localhost 
 JKWorkerProperty worker.tc1.type=ajp13 
 JKWorkerProperty worker.tc1.lbfactor=1 
 
 JKWorkerProperty worker.tc2.port=15209 
 JKWorkerProperty worker.tc2.host=localhost 
 JKWorkerProperty worker.tc2.type=ajp13 
 JKWorkerProperty worker.tc2.lbfactor=1 
 
 JKWorkerProperty worker.tc3.port=15309 
 JKWorkerProperty worker.tc3.host=localhost 
 JKWorkerProperty worker.tc3.type=ajp13 
 JKWorkerProperty worker.tc3.lbfactor=1 
 
 # Define a load balancer worker that uses the three 
 # Tomcat instances 
 
 JKWorkerProperty worker.loadbalancer.type=lb 
 JKWorkerProperty worker.loadbalancer.balance_workers=tc1, tc2, tc3 
 
 # Define the mod_jk status worker 
 
 JKWorkerProperty worker.jkstatus.type=status

It seems that the above configuration in your case is correct, but I would just double check.

I am not sure if you made the following change though:

In the server.xml conﬁguration ﬁle of each Tomcat, you need to set the
jvmRoute attribute of the Engine element to match the corresponding worker name. For instance for the ﬁrst Tomcat instance:

Code:

 ... 
 <Engine name="Catalina" defaultHost="localhost" jvmRoute="tc1"> 
 ...

1. Yes, I am going through port 80.
2. Yes, the configuration is correct.
3. Since I am using localhost and there are no trailing spaces, yes.
4. If I remove Terracotta from the mix, load balancing works correctly (jvmRoute is setup properly).

Could it be because I am running multiple instances on one box? Here are the configs for each instance:

tomcat2:
-Xbootclasspath/p:"C:\Tools\Terracotta\terracotta-2.5.0\lib\dso-boot\dso-boot-hotspot_win32_150_10.jar"
-Dtc.install-root="C:\Tools\Terracotta\terracotta-2.5.0"
-Dtc.config="192.168.1.100:9510,192.168.1.101:9510"
-Dcom.tc.session.serverid=tomcat2

tomcat3:
-Xbootclasspath/p:"C:\Tools\Terracotta\terracotta-2.5.0\lib\dso-boot\dso-boot-hotspot_win32_150_10.jar"
-Dtc.install-root="C:\Tools\Terracotta\terracotta-2.5.0"
-Dtc.config="192.168.1.100:9510,192.168.1.101:9510"
-Dcom.tc.session.serverid=tomcat3

When I look in the client logs, I only see the tomcat2 info in TCProperties since I start it first. When I start tomcat3, it doesn't appear to add any new lines to the log.

I think I have it figured out. The only time I'm having an issue is when I'm in the situation that is described in this mod_jk defect:

http://issues.apache.org/bugzilla/show_bug.cgi?id=44116

Anytime I'm always on the same domain without multiple JSESSIONIDs, everything works as it should.

Sorry for the false alarm.

Thanks,

Darin