[ https://issues.redhat.com/browse/WFLY-13933?page=com.atlassian.jira.plugi... ] Masafumi Miura updated WFLY-13933: ---------------------------------- Description: access-log has a possibility to be lost during WildFly shutdown even if a graceful timeout is specified. If I understand correctly, access-log processing runs on a different thread from the application processing and the graceful shutdown does not care about it. Since WildFly 16+, WFCORE-1632 changed the shutdown behavior to wait only for 100ms (hard-coded). So, WildFly 16+ does not wait for completing a task worker thread processing access-log. I understand the purpose of WFCORE-1632. However, it might be good if we have an option to tune the wait time. (Of course, it would be difficult to know how long wait time is sufficient for completion. And specifying a large wait time can be a cause of long shutdown time. So, it's still questionable how it's useful.) Or, if it's possible to implement that the graceful shutdown can wait for access-log processing, it would be better. (This might be RFE?). was: access-log has a possibility to be lost during EAP 7.3 shutdown even if a graceful timeout is specified. If I understand correctly, access-log processing runs on a different thread from the application processing and the graceful shutdown does not care about it. Since EAP 7.3, WFCORE-1632 changed the shutdown behavior to wait only for 100ms (hard-coded). So, EAP 7.3 does not wait for completing a task worker thread processing access-log. I understand the purpose of WFCORE-1632. However, it might be good if we have an option to tune the wait time. (Of course, it would be difficult to know how long wait time is sufficient for completion. And specifying a large wait time can be a cause of long shutdown time. So, it's still questionable how it's useful.) Or, if it's possible to implement that the graceful shutdown can wait for access-log processing, it would be better. (This might be RFE?). -- This message was sent by Atlassian Jira (v7.13.8#713008)