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. 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
