[server-admins] Tomcat

[Troy A. Griffitts]

Thanks DM for the concise and clear overview of the changes.

I have updated everyone's sudoers rights who previously had access to
/etc/rc.d/init.d/tomcat to also have rights to
/etc/rc.d/init.d/sitestop.sh and sitestart.sh

Please report if you notice any problems.

Troy



On 02/06/2011 04:15 PM, DM Smith wrote:
> FYI,
> This week has seen some significant changes in the setup of tomcat. Troy has implemented partitioning. It's really cool. Here is an overview of what I found:
> 
> In the past, /opt/tomcat was the running instance. Now it is merely the binary home, that is it is merely CATALINA_HOME and no longer also CATALINA_BASE.
> 
> Now the running instances of tomcat are at /opt/tomcat_site1 .. /opt/tomcat_site5.
> 
> The breakdown of the sites:
> site1 - all but what's below
> site2 - community
> site3 - user's accounts, e.g. crosswire.org/~dmsmtih
> site4 - forums
> site5 - jira
> 
> The admin interface is one for each site, just append the site number after manager, e.g. crosswire.org/manager5/html.
> 
> Startup/shutdown - All instances are brought up/down together with the same command as before: /etc/rc.d/init.d/tomcat.
> 
> There is now a new /etc/rc.d/init.d/sitestart.sh and sitestop.sh. Each of these takes a number from 1 to 5, corresponding to the site. These are called by /etc/rc.d/init.d/tomcat.
> 
> In the past when tomcat went rogue and shutting down tomcat did not kill all the java processes, one had to independently kill the java processes, e.g. killall java.
> 
> Now this is a bad idea. Each instance should be managed independently from the other.
> 
> This is accomplished with: sitestop.sh N -force, where N is a site number.
> 
> Details behind this: The environment variable CATALINA_PID has the path to the file containing the PID of the java process. In our implementation it is CATALINA_PID=$CATALINA_BASE/tomcat.pid. The -force argument is provided by tomcat for the purpose of killing the process when it goes rogue.
> 
> This setup allows us to tune instances separately. For example, JIRA needs memory to be tuned to be much larger than default, with XX:MaxPermSize, -Xmx, -Xms.
> These are now provided in $CATALINA_BASE/bin/setenv.sh.
> 
> Advantages:
> CATALINA_HOME no is merely the home for the code. Upgrades are much simpler. It merely can be replaced.
> Each CATALINA_BASE instance is independently managed.
> When one of the webapps or the instance goes rogue, it only affects what is in that one instance.
> Each is individually tuned. This allows for a much smaller footprint for all the instances.
> The logs are much easier to understand. So many of the entries are anonymous. With community, forums, and jira in their own instances, the logs pertain only to them.
> 
> In Him,
> 	DM
> _______________________________________________
> server-admins mailing list
> server-admins at crosswire.org
> http://www.crosswire.org/mailman/listinfo/server-admins