<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">One other question - When a server is
      put into suspend mode, is it going to trigger undeployment of
      certain deployed deployments? And would that be considered the
      expected behaviour? More specifically, when the admin triggers a
      suspend, are the subsystems allowed to trigger certain operations
      which might stop the services that back the currently deployed
      deployments or are they expected to keep those services in a
      started/UP state?<br>
      <br>
      -Jaikiran<br>
      On Tuesday 10 June 2014 10:16 AM, Jaikiran Pai wrote:<br>
    </div>
    <blockquote cite="mid:53968DBD.4080507@gmail.com" type="cite">
      <meta content="text/html; charset=ISO-8859-1"
        http-equiv="Content-Type">
      <div class="moz-cite-prefix">This is more of a subsystem specific
        question - How are internal operations (i.e. something that
        doesn't exactly have an entry point <i>into</i> the server)
        handled when the server is in a suspended state or when it is
        suspending. One such example is, an EJB application which might
        have scheduled timer tasks associated with it. Are such timer
        tasks supposed to continue to run even when server is suspended
        or when it is suspending? Or is the subsystem expected to shut
        those down too?<br>
        <br>
        -Jaikiran<br>
        On Tuesday 10 June 2014 04:08 AM, Stuart Douglas wrote:<br>
      </div>
      <blockquote cite="mid:5396377F.80003@redhat.com" type="cite">
        <pre wrap="">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.

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.

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
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/wildfly-dev">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a>
</pre>
      </blockquote>
      <br>
    </blockquote>
    <br>
  </body>
</html>