Ok, understood. Thanks for taking the time to explain. Allistair.
> -----Original Message----- > From: Shapira, Yoav [mailto:[EMAIL PROTECTED] > Sent: 25 October 2004 14:08 > To: Tomcat Users List > Subject: RE: discussion on webapp reload in production environments > > > > 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] > > <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]
