Hi, Yeah. Webapp reload is a great thought and sometimes possible to do in-place in true-hotswap fashion. Unfortunately in the real world there are several factors which prevent this from really happening. They include:
Libraries that use static resources in such a way they can't be reloaded. Libraries that use System resources (as in System classloader) in such a way they can't be reloaded. Libraries that spawn off their own threads and don't manage them properly. These things can be hard to track, and can be in your code, the library code, or the way your code uses the library. This is exemplified in Bugzilla 26372. Another reason is that real apps frequently do a lot of things on startup (and sometimes shutdown). So the reload even if it worked perfectly would take an unacceptable amount of time. So sites that really can't afford downtime don't do in-place reloading. They have either a server cluster where they update server at a time, taking it off the cluster for the update instead of doing an in-memory reload, or they much with context paths, e.g. /appv1, /appv2, and /app with /app being just forwarding filter. Both of these approaches have been explained and successfully used on this list in the past. There are other approaches as well when you throw other pieces into the mix, such as Apache, Squid, etc. So I'm sure there are people out there doing webapp reload in-memory in true hotswap fashion, and that's great for them. But I think they're the minority and that the state of the industry right now means it's extremely difficult to do it perfectly. Most of things the container can't solve for you. And that's why we take the approach of addressing the issues that are shown conclusively to be Tomcat bugs, and not jumping through hoops to cover faults created by other libraries, because that ultimately reduces the maintainability, speed, and quality of Tomcat itself. By the way, these arguments are not Tomcat-specific (except for the last sentence above obviously ;)). I've had the same experience with the $$$ servers I use. In-memory webapp reload is a good goal, great marketing, and sometimes works well in real life, but not that often. YMMV. Yoav Shapira http://www.yoavshapira.com >-----Original Message----- >From: Allistair Crossley [mailto:[EMAIL PROTECTED] >Sent: Monday, October 25, 2004 4:34 AM >To: [EMAIL PROTECTED] >Subject: discussion on webapp reload in production environments > >Hi, > >Yoav, you suggested we should pick up this thread here in the list rather >than the bugzilla report at >http://issues.apache.org/bugzilla/show_bug.cgi?id=26372 > >I have copied the last 4 replies for any interested parties to start >following this thread. > >I look forward to hearing the position on webapp reloading in terms of >desirable behaviour and the specification when you have time to do so. > >All the best, Allistair. > >YOAV >I'd point out it's only 'dying' when you're trying the >app reload, nor normal usage. This feature is not mandated by the Spec so >we're not obliged to provided it in the first place: it's caused mostly >trouble >and has very limited usage in production environments. So if you have >patches >for it, that's great, but the common usage scenario for Tomcat doesn't >include >webapp reload, and so doesn't suffer from this issue at all. > >ME >I am interested in your comment that reload of webapp is mostly trouble and >limited in production environments though. My understanding was that if you >want to make a build to production or a patch of some files, you would use >ant >or similar as we do here to reconstruct the WAR to deploy. Does this not >require tomcat being able to reload? In fact, we tell the business the >intranet >will be down for 5 minutes and post a message page up for inbound requests. >We >stop tomcat, delete the old war and expanded war files and place the new >war >and startup tomcat again. We constantly get irked by the fact that if a bug >is >on production we have to wait until the evening to patch it whereas our ASP >coutnerparts can so easily hot-patch. We also use JSP precompilation to >improve >performance so it's not so easy to patch JSPs either. > >REMY >I hope hot deployment and redeployment is a reality. However, there are >issues >when the webapp tries to interact with some services which reside in the >system >classloader (logging here). Packaging webapps a little differently could >solve >the problems for now. > >YOAV >Allistair, I'll be glad to continue this discussion on the mailing list and >try >and explain why I think reloading an app in-place has only limited usage in >production environments. This (Bugzilla) is not the right forum for >discussions. > > ><FONT SIZE=1 FACE="VERDANA,ARIAL" COLOR=BLUE> >------------------------------------------------------- >QAS Ltd. >Developers of QuickAddress Software ><a href="http://www.qas.com";>www.qas.com</a> >Registered in England: No 2582055 >Registered in Australia: No 082 851 474 >------------------------------------------------------- ></FONT> > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
