]
Brian Stansberry commented on WFCORE-1632:
------------------------------------------
{code}
I haven't looked closely at the link in the description, but I figure it's
ultimately about using a shared thread pool that is depended upon but not controlled by
the webserver instead of using one that the webserver itself shuts down.{code}
This was wrong. The issue is the change results in the WorkerService MSC service not
stopping until the task being handled by the worker task pool (i.e. the request)
completes. The shutdown hook we install blocks until the MSC service container terminates,
so this prevents that hook completing.
Server processing request isn't stopped immediately but waits for
request processing to finish
----------------------------------------------------------------------------------------------
Key: WFCORE-1632
URL:
https://issues.jboss.org/browse/WFCORE-1632
Project: WildFly Core
Issue Type: Bug
Components: Domain Management, IO, Server
Reporter: Lin Gao
Assignee: Lin Gao
Priority: Critical
Original Estimate: 1 day
Remaining Estimate: 1 day
When stopping server which is processing request, it terminates the connection from the
client but doesn't stop the request processing as such.
After debugging and searching when the issue appeared I've found out that the issue
was introduced with this commit:
[
https://github.com/wildfly/wildfly-core/commit/7304c019705c5f7ec0378e1c51...]
Steps to reproduce:
1) start EAP server with deployed app from attachment
2) create request to long running application: {{curl -i
http://127.0.0.1:8080/long-running-servlet/HeavyProcessing?duration=25000}}
3) stop server (you can do it even gracefully) using {{./jboss-cli.sh -c
":shutdown(timeout=1)"}}
See that server is stopped after 25 seconds since request from step 2 was issued, as that
is duration of the request processing requested by param duration, instead of being
terminated after 1 second.