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
