Pid wrote: > robr wrote: >> >> Pid-2 wrote: >>> Robert Rowntree wrote: >>>> we are running a cluster of 3 nodes. we are on linux . we run tomcat >>>> 5.5.15 >>>> and do not use the server.conf clustering . we cluster tomcat with an >>>> external load balancer. >>> That's a really old Tomcat, lots and lots of bug fixes since then. >>> You should consider upgrading, at least to the latest 5.5 version. >>> >>> ok we will attempt upgrade. >>> >>>> we have tried using a context file like the example below in order to >>>> serve >>>> webapps from the shared drive and have experienced the following >>>> differences >>>> when compared to using locally attached storage for webapps: >>>> >>>> Symptoms: >>>> >>>> 1. On a startup with a new war file positioned in the root directory >>>> for >>>> the webapp the war file does not unpack. ./manager/list shows the app >>>> running but it wont serve anything because war file never expanded. >>>> 2. in 'manager app' , using the GUI request 'reload' and the war file >>>> does not unpack >>>> 3. in 'manager app' , using the GUI request 'undeploy' and the root >>>> directory does not get deleted . the only thing that happens is the >>>> context >>>> file from ./TomcatRoot/conf/Catalina/localhost is deleted. >>>> >>>> >>>> when we put the $myapp.war file in the root directory , the war file does >>>> not expand or unpack on a tomcat startup. >>> "root" is a special word around here; do you mean "webapps" dir? >>> >>> the war file was copy to the 'home' of the context ie to >>> /mnt/nas1data/www/test. this path is on the shared drive. >>> >>>> ./Manager/list shows that 'myapp' >>>> is 'running' but only the war file exists in the directoy. until we run >>>> an >>>> explicit 'jar -xf $myapp.jar' no unpacking occurs. Only with the explicit >>>> command do we get the result that we expect - unpacked war file is the >>>> result. >>>> >>>> Tomcat process runs under a user id that should have 'exec' permissions >>>> in >>>> the directory where the war file is. The context for the webapp includes >>>> a >>>> 'background-processor-thread' . >>> It'll need write permissions if it's going to expand the war file. >>> >>> Tomcat process runs as user 'tomcat'. Tomcat user has write permissions to >>> the directory on the share that is home to the context. >>> >>>> Im trying to figure out whether it is more trouble to do multiple deploys >>>> of >>>> the war file to each node in the cluster or whether we can have a >>>> reliable >>>> procedure redeploying war files to a shared drive running on NFS.. >>> Are you saying that each server is sharing access to the same webapp file? >>> >>> yes . In the respective ./serverHomePath/conf/Catalina/localhost/ >>> directory on the servers is a copy of the same context - >>> /mnt/nas1data/www/test. So all servers would load classes and get >>> resources from the share. >>> >>> Each Tomcat might try to expand the war file into the same shared >>> directory, which could produce unpredictable outcomes. >>> >>> The assumption was that , on a redeploy, once the file system on the share >>> was refreshed with the new copy of the files belonging to the webapp, that >>> on the other servers , a 'stop' followed by a 'start' would result in the >>> classloader on each respective server processing a reload of the classes >>> without re-expanding the war. I guess that we could turn on debug in the >>> Catalina.core package in order to verify that. > > You understand the point I'm trying to make? > You've started out by saying that you want the war to expand. > > 1. new war is uploaded. > 2. server1 is restarted > 2a expanded dir is removed > 2b war is expanded > > 2. server2 is restarted... > 3. etc > > > If servers other than server1 need to access the expanded war in between > 2a and 2b then there will be a problem, as the app isn't there any more. > > AFAIK the war will be re-expanded for each server as the timestamp for > the war file is the thing that is monitored. So at during each restart > the other servers may experience problems.
Correction: unless you have deployOnStartup="false" autoDeploy="false", reloadable="false" and are manually deploying - but even then, the loss of service for other apps is still likely. p > Multiple servers sharing the same war file is Very Bad Idea. If you > want to keep the war on a shared disk, you might at least make separate > dirs: > > /mnt/nas1data/www1/test > /mnt/nas1data/www2/test > /mnt/nas1data/www3/test > > > Alternatively write a deployment script, (using Ant, perhaps), that > uploads the war and restarts each server separately. > > (Also the context.xml file shouldn't usually contain the path or docBase > attributes, especially if it's in the expected place > app.war/META-INF/context.xml) > > > p > > >>> Disk space is cheap: the amount of time you've already spent doing this >>> has probably negated any savings in deployment that you might have been >>> hoping for. >>> >>> Can you make the webapp work when it's deployed locally on each server? >>> >>> It works fine when deployed to each server's locally attached storage. The >>> point was an easier deploy step given that the servers involved are a mix >>> of OS's and that we might not want to repeat a 'redeploy ' to each server. >>> "write once run everywhere ... " can also apply to file deployments and >>> expanding war files in that we are interested in doing a single deployment >>> step and having the respective servers simply pick up the change. I guess >>> it depends on how automated you are with the 'deploy' infrastructure. >>> >>> thank you for the quick reply. >>> >>> p >>> >>> >>>> --- context file for the webapp: >>>> >>>> <Context path="/test" docBase="/mnt/nas1data/www/test" override="true" >>>> backgroundProcessorDelay="10" /> >>> Where is this context file placed/found? >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>> For additional commands, e-mail: users-h...@tomcat.apache.org >>> >>> >>> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
