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.
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.
If stop is called on the connector, it will stop without affecting the webapp.
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.
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?
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.
