tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject RE: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/core C
Date Fri, 01 Dec 2000 22:18:18 GMT
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 
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.


View raw message