> > Why bother un-deploying and then shutting-down? A shutdown > undeploys all applications, first, anyway. I think you're > just complicating the process.
We were just being paranoid. We were seeing issues before with tomcat serving the wrong version of an application even though we believed we deployed a different version. Just stopping the service and deleting files should be good enough. > > I'm not sure about auto-deploy and auto-undeploy, but auto > reload can be significant. I believe that, by default, Tomcat > watches WEB-INF/web.xml, any JAR file loaded for the > application, and any .class file loaded for the application, > for changes. Since Tomcat uses exploded WAR files, I'm > guessing that it watches a /lot/ of files, and it scans then > every 15 seconds or so. It also requires memory to store the > original file date for each file being watched, etc. > > I have auto-deploy on for production, but I only have 1 > webapp per Tomcat instance, so I'm pretty sure it's not > working all that hard. I leave it on to simplify my > deployment (don't have to copy META-INF/context.xml into > $CATALINA_HOME/conf/.../... to deploy). I aggree that it can be a lot more files but I just can't believe that monitoring 1000 files or there about would have any significant memory impact. Considering that our tomcat servers at least have all 4Gb memory, that should be drop in the ocean. Running stat on each file every 15s could perhaps have a impact. Best way would be to measure this for ourselves. Ideally if one can develop a relatively fool proof method to measure performance with auto deploy on and off then one could gather imperical evidence for the impact it has or has not. > If you are using auto-deploy, then the context name is the > WAR file name without the ".war" extension. So, for instance, > foo.war is deployed into "/foo". The special name ROOT.war > will auto-deploy to "/". Would auto-deploy ignore "context path" if specified in the META-INF/context.xml ? > > > An interesting idea... How would you make your tomcat unavailable > > during the re-deployement of a new application? > > While Tomcat is undeploying and re-deploying an application, > the application is already (temporarily) unavailable. Did you > need something more interesting? > What I am not sure about is how mod_jk would tell apache that the application is not available and if it would do so at all. We are seeing 404 errrors while a new version of an application gets deployed. The safest way is to make the lb_factor 0 while deploying and then changing it back to x when the application has finished deploying. I was wondering whether there are a tool that "spans" accross a tomcat/apache infrastructure that would change apache settings specifically worker.properties to reflect the unavailability of a tomcat server while it is being upgraded and then adding it back in. Ideally you would want a way of tomcat being able to tell mod_jk conclusively about its availability or lack there of and mod_jk adjusting itself automatically on the apache side to not send load to the specific tomcat server. Regards ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________
