Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
From: cmanolache@yahoo.com
Date: Fri, 1 Dec 2000 14:18:18 -0800 (PST)
To: "'tomcat-dev@jakarta.apache.org'" <tomcat-dev@jakarta.apache.org>
Subject: RE: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/core C
 ontextManager.java
In-Reply-To: <764CA2FF49EC054BA086FC8253A52DD7433265@merc09.us.sas.com>
Message-ID: <Pine.LNX.4.21.0012011409250.1868-100000@costin>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi Larry,

> during shutdown.  This patch keeps it from getting stuck, but
> if the context was in "STATE_READY", then "shutdownContext( context )"
> is called which sets the state to "STATE_DISABLED" causing
> removeContext() to exit early.  The interceptor's removeContext()
> methods won't be called.  

I fixed that - but I'm not sure what's the right order: 
should we 
add -> init -> shutdown -> remove 
or
init-> add -> remove -> shutdown ?

The second seems much better ( the context may be initialized but not in
use, for example if an admin wants to temporarily disable a context)

All the "context state" is new in 3.3 - for 3.2 it just happens to works (
because we fixed everything to work in most cases, without a clear
definition ). 


> While pondering a fix for this, I was also pondering what should
> happen if an interceptor throws an exceptions during context
> removal.  Currently, an exception would get handled outside
> of ContextManger and potentially leave a context in an inconsistent
> state.  Should interceptor exceptions be caught, logged, then
> ignored by ContextManager so shutdown can proceed without being
> aborted?

Yes, you are right - I'll fix this. 

Should it be the case for all context callbacks ? I think engineInit
exceptions should be propagated ( and the server shouldn't start after
that). Probably the same for contextAdd/contextInit - if any exception
happens, the context will be disabled.

I agree that shutdown errors should be ignored ( logged only ).

> Also, it seems to me that a Tomcat shutdown will remove the contexts
> out from under any requests that are currently using it.  Am I
> missing something?  If not, should we try to add, or at least
> provide for, an "orderly" shutdown in addition to the "forced"
> shutdown we seem to currently have?

I was thinking that this should be done in an interceptor - shutdown can
wait until all requests for that context are done ( with a timeout ). It
would be nice to have this.

Costin