Re: [wildfly-dev] Design Proposal: Server suspend/resume (AKA Graceful Shutdown)

They are actually orthogonal, a server can be in both RESTART_REQUIRED and any one of the suspend states. RESTART_REQUIRED is very much tied to services and the management model, while suspend/resume is a runtime only thing that should not touch the state of services. Stuart Dimitris Andreadis wrote: > Why not extend the states of the existing 'server-state' attribute to: > > (STARTING, RUNNING, SUSPENDING, SUSPENDED, RESTART_REQUIRED RUNNING) > > http://wildscribe.github.io/Wildfly/8.0.0.Final/index.html > > On 10/06/2014 04:40, Stuart Douglas wrote: >> >> Scott Marlow wrote: >>> On 06/09/2014 06:38 PM, Stuart Douglas wrote: >>>> Server suspend and resume is a feature that allows a running server to >>>> gracefully finish of all running requests. The most common use case for >>>> this is graceful shutdown, where you would like a server to complete all >>>> running requests, reject any new ones, and then shut down, however there >>>> are also plenty of other valid use cases (e.g. suspend the server, >>>> modify a data source or some other config, then resume). >>>> >>>> User View: >>>> >>>> For the users point of view two new operations will be added to the server: >>>> >>>> suspend(timeout) >>>> resume() >>>> >>>> A runtime only attribute suspend-state (is this a good name?) will also >>>> be added, that can take one of three possible values, RUNNING, >>>> SUSPENDING, SUSPENDED. >>> The SuspendController "state" might be a shorter attribute name and just >>> as meaningful. >> This will be in the global server namespace (i.e. from the CLI >> :read-attribute(name="suspend-state"). >> >> I think the name 'state' is just two generic, which kind of state are we >> talking about? >> >>> When are we in the RUNNING state? Is that simply the pre-state for >>> SUSPENDING? >> 99.99% of the time. Basically servers are always running unless they are >> have been explicitly suspended, and then they go from suspending to >> suspended. Note that if resume is called at any time the server goes to >> RUNNING again immediately, as when subsystems are notified they should >> be able to begin accepting requests again straight away. >> >> We also have admin only mode, which is a kinda similar concept, so we >> need to make sure we document the differences. >> >>>> A timeout attribute will also be added to the shutdown operation. If >>>> this is present then the server will first be suspended, and the server >>>> will not shut down until either the suspend is successful or the timeout >>>> occurs. If no timeout parameter is passed to the operation then a normal >>>> non-graceful shutdown will take place. >>> Will non-graceful shutdown wait for non-daemon threads or terminate >>> immediately (call System.exit()). >> It will execute the same way it does today (all services will shut down >> and then the server will exit). >> >> Stuart >> >>>> In domain mode these operations will be added to both individual server >>>> and a complete server group. >>>> >>>> Implementation Details >>>> >>>> Suspend/resume operates on entry points to the server. Any request that >>>> is currently running must not be affected by the suspend state, however >>>> any new request should be rejected. In general subsystems will track the >>>> number of outstanding requests, and when this hits zero they are >>>> considered suspended. >>>> >>>> We will introduce the notion of a global SuspendController, that manages >>>> the servers suspend state. All subsystems that wish to do a graceful >>>> shutdown register callback handlers with this controller. >>>> >>>> When the suspend() operation is invoked the controller will invoke all >>>> these callbacks, letting the subsystem know that the server is suspend, >>>> and providing the subsystem with a SuspendContext object that the >>>> subsystem can then use to notify the controller that the suspend is >>>> complete. >>>> >>>> What the subsystem does when it receives a suspend command, and when it >>>> considers itself suspended will vary, but in the common case it will >>>> immediatly start rejecting external requests (e.g. Undertow will start >>>> responding with a 503 to all new requests). The subsystem will also >>>> track the number of outstanding requests, and when this hits zero then >>>> the subsystem will notify the controller that is has successfully >>>> suspended. >>>> Some subsystems will obviously want to do other actions on suspend, e.g. >>>> clustering will likely want to fail over, mod_cluster will notify the >>>> load balancer that the node is no longer available etc. In some cases we >>>> may want to make this configurable to an extent (e.g. Undertow could be >>>> configured to allow requests with an existing session, and not consider >>>> itself timed out until all sessions have either timed out or been >>>> invalidated, although this will obviously take a while). >>>> >>>> If anyone has any feedback let me know. In terms of implementation my >>>> basic plan is to get the core functionality and the Undertow >>>> implementation into Wildfly, and then work with subsystem authors to >>>> implement subsystem specific functionality once the core is in place. >>>> >>>> Stuart >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> The >>>> >>>> A timeout attribute will also be added to the shutdown command, >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev