tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Allistair Crossley" <Allistair.Cross...@QAS.com>
Subject RE: discussion on webapp reload in production environments
Date Mon, 25 Oct 2004 13:12:40 GMT
Ok, understood. Thanks for taking the time to explain.

Allistair.

> -----Original Message-----
> From: Shapira, Yoav [mailto:Yoav.Shapira@mpi.com]
> 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:Allistair.Crossley@QAS.com]
> >Sent: Monday, October 25, 2004 4:34 AM
> >To: tomcat-user@jakarta.apache.org
> >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: tomcat-user-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
> 
> 
> 
> 
> 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: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
> 
> 


<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: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org


Mime
View raw message