[server-admins] Tomcat

[Troy A. Griffitts]

PS.  DM is modest when he says "Here is an overview of what I found."
Thanks DM for cleaning up my hacked startup scripts and reading through
the catalina.sh startup to steer us in the right direction, and for
getting jira back up and running again.



On 02/07/2011 03:42 AM, Troy A. Griffitts wrote:
> 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
> 
> 
> _______________________________________________
> server-admins mailing list
> server-admins at crosswire.org
> http://www.crosswire.org/mailman/listinfo/server-admins