-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Gerhardus,
[EMAIL PROTECTED] wrote: >> 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 agree 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. The memory impact is low. It's the fact that your application has to waste CPU (and disk) time scanning all those files. Sure, a single scan isn't that bad, but if you're doing it every 15 seconds or so, it's taking away CPU time from your own application. > 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 impartial > evidence for the impact it has or has not. I'm always a fan of not doing anything you don't have to. There's no question that you will increase the performance of your application by disabling the auto-deployment features of Tomcat. The difference may be undetectable, but it's a simple change, requires virtually no testing, and is guaranteed to reduce the amount of work that Tomcat does regularly. What's the downside? >> 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 ? If you use auto-deploy and you have a WAR file or directory in the "webapps" directory, then any "path" attribute you have in your <Context> element will be ignored (or, worse, confused and used ion some weird way). Perhaps this is a problem with your deployment. > 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 > errors while a new version of an application gets deployed. IIRC, Tomcat issues something like a 503 "Unavailable" response when the application is undergoing a deployment. You ought to be able to use an ErrorDocument directive to display a "we're restarting" page to your users. I wouldn't have expected a 404 error. Then again, if you are deleting the files yourself instead of having Tomcat do the undeploy-redeploy cycle itself, then you could be seeing weird things. > 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. That sounds like a horrible hack. :( > 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. Talk to the mod_jk devs about this. They lurk on this list, so feel free to ask a more specific question about the availability or desirability of such a feature. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGuJ5O9CaO5/Lv0PARAqGjAJ0QZ5boVromZhogGW4kkgQ15F5a7gCgl37T 7+Sh+2FI36dJrmDl3iIzWEU= =KarX -----END PGP SIGNATURE----- --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
