The use case is Graceful Shutdown in a Kubernetes environment. The current Wildfly instance receives a TERM signal and the new instance is ready for accepting new HTTP client connections.  

The graceful shutdown process starts many seconds after receiving the TERM signal. After receiving the TERM signal, Wildfly still responds to incoming HTTP requests. 

Moreover, during the SUSPENDING state, Wildfly should respond with HTTP Close Connection header, giving a chance to clients which use a persistent connection of creating a new connection to the new Wildfly instance.

For example, these are the logs:

2023-02-07 11:44:55,927 [default task-1] INFO  [ems-ppm-app-ws,8361c42f1030ce13] it.tasgroup.ems.ppm.web.rs.config.LoggingFilter - Received GET request to URL http://ems-ppm-app-ws-unipol:8080{{{}

ERROR *** WildFly wrapper process (1) received TERM signal ***{}}}

2023-02-07 11:44:55,986 [default task-1] INFO  [ems-ppm-app-ws,66ecfbb997f621ce] it.tasgroup.ems.ppm.web.rs.config.LoggingFilter - Received GET request to URL http://ems-ppm-app-ws-unipol:8080

.....

..........

11:44:59,609 INFO  [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0211: Suspending server with 60000 ms timeout.

Wildfly actually goes into SUSPENDING state after 5 seconds and does not close persistent (i.e Keep-Alive) connections.