Le fichier ${build.shortName} peut être suspendu ou fermé gracieusement. Cela permet aux demandes actives de se terminer normalement, sans accepter de nouvelles demandes. Une valeur de délai d'attente spécifie pendant combien de temps l'opération de mise en attente ou d'arrêt durera en attendant que les demandes actives soient terminées. Pendant que le serveur est suspendu, les demandes de gestion sont toujours traitées.

Un arrêt en douceur est coordonné à l'échelle du serveur, principalement centré sur les points d'entrée par lesquels une requête entre dans le serveur. Les sous-systèmes suivants prennent en charge l'arrêt en douceur :

Undertow: Le sous-système Undertow attendra que toutes les requêtes soient terminées.
Modcluster: Le sous-système modcluster avertira l'équilibreur de charge que le serveur est mis en attente dans la phase PRE_SUSPEND.
EJB: Le sous-système ejb3 attendra que toutes les requêtes EJB et que les livraisons de messages MDB à distance soient terminées. La livraison aux MDB est interrompue dans la phase PRE_SUSPEND. Les minuteries EJB sont suspendues et les minuteries manquées seront activées à la reprise du serveur.
EE Concurrence: Le serveur attendra que tous les travaux actifs soient terminés. Tous les travaux en file d'attente seront ignorés. Simultanément, puisque la concurrence en matière d'EE n'a pas de persistance, les tâches en attente qui ont été ignorées seront perdues.
Pendant que le serveur est dans un état suspendu, les tâches planifiées continueront à s'exécuter à leur heure prévue mais émettront une exception java.lang.IllegalStateException. Une fois que le serveur reprend, les tâches planifiées continueront à s'exécuter normalement et dans la plupart des cas, les tâches n'auront pas besoin d'être reprogrammées.
Lot: Le serveur arrêtera tous les travaux en cours d'exécution pendant la période de temporisation et reportera tous les travaux planifiés.
Un arrêt en douceur ne rejettera pas les transactions distribuées à distance ou les nouveaux messages JMS entrants. Les jobs par lots EE et les tâches simultanées EE programmées par l’activité en vol sont actuellement autorisées. Cependant, les tâches concurrentes EE soumises qui vont au delà de la fenêtre de temporisation sont simultanément en erreur lorsqu'elles sont exécutées.

Les requêtes sont suivies par le sous-système request-controller. Sans ce sous-système, les capacités de suspension et de reprise sont limitées et le serveur n'attendra pas que les requêtes soient terminées avant de suspendre ou de fermer. Cependant, si vous n'avez pas besoin de cette capacité, le sous-système request-controller peut être retiré pour une petite amélioration des performances.