RE: Best practice application deployement
> 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? Aggreed. > > >> 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 element will be ignored (or, worse, > confused and used ion some weird way). Perhaps this is a > problem with your deployment. That explains a lot, I have recommended that we drastically rethink our deployment methodology > > > 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. We are only a middle man, in that we provide a xml interface for other website to search our database. We don't want any errors at all or downtime. We get about 30million search requests a day so any downtime has significant impact on clients. > > 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. :( I probably aggree, reason being why I have asked if anyone knows about a better way to do this. Regards __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
Re: Best practice application deployement
-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 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]
Re: Best practice application deployement
On the other hand you could disable on the fly compiling and hence checking for updates (tomcat checks if the jsp page has been changed and if there is a need to recompile it). Disabling this can get you some performance boost and reduce io. Of course it only matters if you really have traffic. leon On 8/7/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Hi Leon, > > If the jsp gets compiled once after the war files get deployed then I would > be willing for the server to be a bit less responsive for the 2 minutes or > so that it takes for the application to deploy. > > Assuming that you would deploy by copying files, copying one war file for me > is simpler then copying a directory or larger collection of files. > > Regards > > > -Original Message- > > From: Leon Rosenberg [mailto:[EMAIL PROTECTED] > > Sent: 07 August 2007 10:58 > > To: Tomcat Users List > > Subject: Re: Best practice application deployement > > > > I concluded that from statements from Remy on different > > occasions; Jason Brittain also mentions it in his new book, > > and finally our production experience tells us that its > > better to. Unless you want your server to be busy compiling > > jsps instead of serving requests some time after start :-) > > > > regards > > Leon > > > __ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > __ - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Best practice application deployement
> > 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 __
Re: Best practice application deployement
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gerhardus, [EMAIL PROTECTED] wrote: > If the jsp gets compiled once after the war files get deployed then I would > be willing for the server to be a bit less responsive for the 2 minutes or > so that it takes for the application to deploy. The problem is that JSPs are not compiled until they are accessed for the first time. This means that your application will feel sluggish until all popular pages have been hit at least once. Pre-compiling JSPs simply avoids this compile-on-demand step (but, of course, increases deployment time due to the time to pre-compile -- but if deployed correctly, Tomcat's downtime is minimized). > Assuming that you would deploy by copying files, copying one war file for me > is simpler then copying a directory or larger collection of files. If you use a tool like ant, or even a shell script (as you already do), then you don't really have to worry about the complexity of the deployment process: you just type "do it" and it gets done. Yes, it's more complicated to work-out at first, but you may see a performance improvement because of it. I'm never a fan of premature optimization, though. If you're not having any problems, don't change anything. Just keep this in mind for the future, just in case you need it. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGuH4S9CaO5/Lv0PARAjtVAJ9IrNMPztso0i+wDs7S8zPm8ipnhgCbB07f fZ+7dQwOkiYf1/aVRRqrmB4= =sX9b -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]
Re: Best practice application deployement
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gerhardus, [EMAIL PROTECTED] wrote: >> Ouch. Why do you delete the application before you stop >> Tomcat? I would stop Tomcat and then delete the files. > > We delete the war file before stopping tomcat to give Tomcat a chance to > auto-undeploy the application automatically. Why bother un-deploying and then shutting-down? A shutdown undeploys all applications, first, anyway. I think you're just complicating the process. > I just read last night that auto-deploy/undeploy carries a performance > impact, is the performance impact really that significant just for > monitoring a directory? 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). >> How does this even work? The first line of the script deletes >> /home/admin/application-1.1.war and the second-to-last line >> tries to copy it back. Shouldn't the file not even exist? > > The problem as I am made to understand from the developers is that the > context name is dependant on the application name and that specifically > specifying a context name does not do the trick. 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 "/". > 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? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGuHuF9CaO5/Lv0PARApdXAKC7eJpQki8qVraEWYcEQem1fJPnCwCfQfgX KaYFO7ulsg+C0DcB3PNFStE= =bF6Q -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]
RE: Best practice application deployement
Hi Leon, If the jsp gets compiled once after the war files get deployed then I would be willing for the server to be a bit less responsive for the 2 minutes or so that it takes for the application to deploy. Assuming that you would deploy by copying files, copying one war file for me is simpler then copying a directory or larger collection of files. Regards > -Original Message- > From: Leon Rosenberg [mailto:[EMAIL PROTECTED] > Sent: 07 August 2007 10:58 > To: Tomcat Users List > Subject: Re: Best practice application deployement > > I concluded that from statements from Remy on different > occasions; Jason Brittain also mentions it in his new book, > and finally our production experience tells us that its > better to. Unless you want your server to be busy compiling > jsps instead of serving requests some time after start :-) > > regards > Leon __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
Re: Best practice application deployement
I concluded that from statements from Remy on different occasions; Jason Brittain also mentions it in his new book, and finally our production experience tells us that its better to. Unless you want your server to be busy compiling jsps instead of serving requests some time after start :-) regards Leon On 8/7/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Hi Leon, > > > -Original Message- > > From: Leon Rosenberg [mailto:[EMAIL PROTECTED] > > Sent: 07 August 2007 09:40 > > To: Tomcat Users List > > Subject: Re: Best practice application deployement > > > > just a side note, the recommended deployment for production > > environment isn't a war file. instead put the webapp folder > > directly under webapps (or whenever your docroot directory > > is) AND put precompiled jsps under work. > > Out of curiosity do you know why a webapp folder is better or recommended as > opposed to using a war file. To be honest I have no idea what the difference > is. I am immerging myself in the tomcat world but there is a lot to learn. > Could you provide a link that substantiate this recommendation of not using > war files? > > Regards > > > __ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > __ - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Best practice application deployement
Hi Leon, > -Original Message- > From: Leon Rosenberg [mailto:[EMAIL PROTECTED] > Sent: 07 August 2007 09:40 > To: Tomcat Users List > Subject: Re: Best practice application deployement > > just a side note, the recommended deployment for production > environment isn't a war file. instead put the webapp folder > directly under webapps (or whenever your docroot directory > is) AND put precompiled jsps under work. Out of curiosity do you know why a webapp folder is better or recommended as opposed to using a war file. To be honest I have no idea what the difference is. I am immerging myself in the tomcat world but there is a lot to learn. Could you provide a link that substantiate this recommendation of not using war files? Regards __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
Re: Best practice application deployement
just a side note, the recommended deployment for production environment isn't a war file. instead put the webapp folder directly under webapps (or whenever your docroot directory is) AND put precompiled jsps under work. regards Leon On 8/6/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Hi > A quick google showed that one could possibly use a maven plugin to > automatically deploy war files or ant. > > If you have a fairly large infrastructure eg: > 6 Apache clusters(two servers configured active/passive) each with about 10 > Tomcats. > > How would you do the following: > * Quickly deploy a new or updated war file > * Take a tomcat out of the load balancing configuration on the apache to > upgrade/downgrade it and adding it back in. > Currenlty we have a script that sets the lbfactor to 0 and then deploys a > new application. > > > Currently when deploying a new set of war files we do the following in a > script that runs for all our servers. > rm -rf /home/admin/application-1.1.war > rm -rf /usr/share/tomcat5/webapps/application-1.1.war > sleep 20s > /etc/init.d/tomcat5 stop > rm -rf /usr/share/tomcat5/work/Catalina/localhost/application-1.1 > rm -rf /usr/share/tomcat5/conf/Catalina/localhost/application-1.1.xml > rm -rf /usr/share/tomcat5/webapps/application-1.1 > cp /home/admin/application-1.1.war /usr/share/tomcat5/webapps > /etc/init.d/tomcat5 start > > > The idea of the script is to allow tomcat to undeploy the application and > then delete the files anyway if it did or did not work. > > #The file name is the same as the old one to enable the context to stay the > same. > /etc/init.d/tomcat5 start" > > I am almost certain there are better ways to do what we are doing and would > appreciate any ideas. > > Regards > > > __ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > __ - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Best practice application deployement
Hi Christopher, > > Ouch. Why do you delete the application before you stop > Tomcat? I would stop Tomcat and then delete the files. We delete the war file before stopping tomcat to give Tomcat a chance to auto-undeploy the application automatically. I just read last night that auto-deploy/undeploy carries a performance impact, is the performance impact really that significant just for monitoring a directory? > > rm -rf /usr/share/tomcat5/work/Catalina/localhost/application-1.1 > > rm -rf > /usr/share/tomcat5/conf/Catalina/localhost/application-1.1.xml > > rm -rf /usr/share/tomcat5/webapps/application-1.1 > > cp /home/admin/application-1.1.war /usr/share/tomcat5/webapps > > /etc/init.d/tomcat5 start > > How does this even work? The first line of the script deletes > /home/admin/application-1.1.war and the second-to-last line > tries to copy it back. Shouldn't the file not even exist? The problem as I am made to understand from the developers is that the context name is dependant on the application name and that specifically specifying a context name does not do the trick. I have not tested this myself yet, but plan to do so. Even though the file name in the script are the same it is a different file or different version at least of the same application. > > ant has an optional task to allow you to (re-)deploy WAR > files to a running Tomcat instance. This capability is > probably inherited by Maven, which is how you heard about it. > Maven is not required, though, so if you aren't using Maven, > you don't have to. > > Are your servers sharing any remote-mounted filesystems over > NFS or anything like that? I believe that Tomcat expands > deployed WAR files to its local work directory, so you could > potentially share WAR files over a network-mounted disk. > Then, simply replace the WAR file on the network and all 60 > of your Tomcat instances will auto-re-deploy if configured to > do so. (I wouldn't recommend this for production, but that's > just my own personal bias). An interesting idea... How would you make your tomcat unavailable during the re-deployement of a new application? Regards __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
Re: Best practice application deployement
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gerhardus, [EMAIL PROTECTED] wrote: > Currently when deploying a new set of war files we do the following in a > script that runs for all our servers. > rm -rf /home/admin/application-1.1.war > rm -rf /usr/share/tomcat5/webapps/application-1.1.war > sleep 20s > /etc/init.d/tomcat5 stop Ouch. Why do you delete the application before you stop Tomcat? I would stop Tomcat and then delete the files. > rm -rf /usr/share/tomcat5/work/Catalina/localhost/application-1.1 > rm -rf /usr/share/tomcat5/conf/Catalina/localhost/application-1.1.xml > rm -rf /usr/share/tomcat5/webapps/application-1.1 > cp /home/admin/application-1.1.war /usr/share/tomcat5/webapps > /etc/init.d/tomcat5 start How does this even work? The first line of the script deletes /home/admin/application-1.1.war and the second-to-last line tries to copy it back. Shouldn't the file not even exist? ant has an optional task to allow you to (re-)deploy WAR files to a running Tomcat instance. This capability is probably inherited by Maven, which is how you heard about it. Maven is not required, though, so if you aren't using Maven, you don't have to. Are your servers sharing any remote-mounted filesystems over NFS or anything like that? I believe that Tomcat expands deployed WAR files to its local work directory, so you could potentially share WAR files over a network-mounted disk. Then, simply replace the WAR file on the network and all 60 of your Tomcat instances will auto-re-deploy if configured to do so. (I wouldn't recommend this for production, but that's just my own personal bias). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGt1909CaO5/Lv0PARAvBhAKC5BQ8zYYV5WXdIWtLYL1ohhpAASgCeJcWZ RkB09fp89Z94g2cQ4RzLkUI= =AzeT -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]
