|Home > Apache Geronimo v1.1 > Documentation > Apache Geronimo v1.1 - User's Guide > Sample applications > Geronimo Tomcat Context Level Clustering - Sample Application|
|Exposing Web applications on distinct ports||Sample applications||Geronimo Tomcat Host Level Clustering - Sample Application|
This web tier clustering sample applies to a Geronimo with Tomcat distribution.
This example demonstrates how to use context level clustering with the Tomcat web container in Geronimo. It contains the necessary attachments for setting up cluster members on two separate physical machines. The cluster configuration will allow the two cluster members to replicate httpsession data via memory to memory multicast communication. Also, a load balancer can be used to spray the incoming requests to the available cluster members. In this example, we recommend Apache HTTP server and Apache mod_jk.
|"Context level" clustering has a known bug in Tomcat as reported in https://issues.apache.org/jira/browse/GERONIMO-2577 and http://issues.apache.org/bugzilla/show_bug.cgi?id=41620. Hence we recommend that you use "Host level" clustering as documented in http://cwiki.apache.org/GMOxDOC11/geronimo-tomcat-host-level-clustering-sample-application.html.|
Installing the Example
This example contains 4 attachments:
Each geronimo cluster member must have a unique jvmRoute designation. The jvmRoute attribute allows the mod-jk load balancer to provide "sticky session" (sending all requests for the same httpsession to the same cluster member). This is possible since the load balancer places the jvmRoute value in the session cookie (or encoded url) that is returned to the web browser.
The jvmRoute attribute can be set by updating the var/config/config.xml file by adding the lines indicated in bold below.
Remember that the jvmRoute value must be unique for each cluster member and the server must be stopped when updating config.xml.
Now start the geronimo server (e.g. bin/geronimo.bat|sh run) and deploy the example on each of the cluster members. For this example, the applications are slightly different for each cluster member. The difference is merely to indicate the current Server number (e.g. Server 1, Server 2) in the output of the application. This will be useful when trying to determine which cluster member is servicing the http request from the browser.
Install the attached applications to the appropriate cluster member assuring that you use the correct deployment plan for each member. Note that the deployment plan must be updated with the hostname (or IP address) for each machine. The appropriate spots are identified in the plans with xx.yy.zz.aa.
Once you get the applications installed on each cluster member, you can test httpsession replication by hitting the application with your favorite browser. Probably something like: http://localhost:8080/servlets-examples-cluster/servlet/SessionExample . Note that the output page contains the ID of the server that is servicing the request. In your browser window, fill in the appropriate input fields and hit the submit button. The console dialogue (the prompt where you started geronimo) should show that that httpsession data is being transmitted and received between the cluster members. Note that the transmit/receive confirmation messages in the log are only present for Tomcat 5.5.12.
Load Balancing and failover
Now you are ready to setup the Load Balancer. We recommend using Apache HTTP server and mod_jk for this example.
Install Apache HTTP server - instructions and downloads available at http://httpd.apache.org/
Install Apache mod_jk - See http://tomcat.apache.org/tomcat-5.5-doc/balancer-howto.html
Configuration tips for mod_jk:
Note that worker.nodeXYZ values should agree with the jvmRoute values that were used in the config.xml for each node.
Testing Load Balancing and Failover
Once you get Apache HTPP Server and mod_jk setup correctly.. You can test load balancing and failover by requesting the following URLs on port 80 (Apache HTTP Server default port).
http://Yourhost/servlets-examples-cluster - HttpSession is not used here, hence no sticky session
http://Yourhost/servlets-examples-cluster/servlet/SessionExample - HttpSession is used here, hence sticky session should be in effect
You can test failover by stopping the geronimo server that owns the sticky session and seeing that the next http request will failover into the remaining cluster member. The httpsession data from the previous request should be recovered and displayed in the refreshed browser window.
Also, see http://tomcat.apache.org/tomcat-5.0-doc/cluster-howto.html for more information on tomcat clustering.
Special Acknowledgement to Jeff Genender for developing and supporting the Tomcat clustering GBeans for Geronimo!!
Back Button Sample applications