On Jan 28, 2004, at 6:51 PM, Greg Wilkins wrote:
Dain Sundstrom wrote:Section 2.7 Run States:
I don't think we need additional states. When a component has stop() invoked, the component immediately moves to the stopping state. In most cases this is followed by a call to doStop, which can throw a WaitingException. I think you can move jetty to gradual shutdown, throw an WaitingException, and when all threads have exited you would call context.stop();
Another badly written use case with implementation details in it. The use case should simply that we need graceful shutdown by session, connection and request. I'll remove mention of states etc.
As for the implementation of this, I was not proposing extending the JSR77 state model. I do think that some components will need substates withing the JSR77 stopping state to track what they are waiting for (eg number of sessions to reduce below threshhold).
The configuration and control of graceful shutdown is also more than
can be communicated by a simple stop() call. This probably should be
configuration of the context/connector that is used once a JSR77 stop is
called. But if an operator get's sick of waiting for a graceful shutdown,
is it acceptable for them to change this configuration while the component
is in the stopping state? eg. The operator may start a graceful shutdown, then
after 20 minutes when the number of connections has reduced to 2 or 3 do a
slightly less than graceful shutdown to complete the stop - I'll add this
to the use-case.
It is always ok to change attributes as long as the gbean can handle it.
I was thinking that we always assume a graceful shutdown and if that takes to long the admin could call some sort of killAllConnections method.
The one issues is doStop is not called until all dependent services have stopped, which may not be what you want.
I think the dependancies do work the right way around. If a connector is dependant on a webapplication, then it will not accept connections until the webapp is started.
right... if a connector is dependent on a web application is can not start until the web application is running, and it must be stopped before the web application can stop
If stop is called on the connector, it will stop without affecting the webapp.
right
If stop is called on the webapp, then the doStop is called on the connector before the webapp is stopped. Thus if a request is accepted by that connector, the webapp *will* be started, which is what we want.
right
The trick will be to do session bleeding in the connector stop, as sessions are a context thing. Is is possible to attache behaviour to the stop call, or is everything meant to be in the doStop?
Everything is meant to be in do stop, but we can change things if there is a need.
My confusion was based on my assumption the the dependencies were as follows:
Jetty<--Connector<--Webapplication<--Servlets
which is wrong
Anyway, I believe that we have enough states, but we may need to use them more effectively.
True - I wasn't proposing extending the JSR77 states - just that some web
components may have nested sub-states within the JSR77 stopping state.
That make sense.
-dain
