[
https://issues.jboss.org/browse/MODCLUSTER-408?page=com.atlassian.jira.pl...
]
Radoslav Husar commented on MODCLUSTER-408:
-------------------------------------------
{quote}But I also note the undeploy as a whole is still progressing during the request
draining. Should we expect mod_cluster to delay the undeploy until requests are drained or
the stop-context- timeout passes?{quote}
There is not much we can do until we support a form of graceful shutdown, i.e. WFLY-1247.
The best is for the customer to draing the sessions first using the console and then
proceed with the shutdown.
Requests are not properly drained during undeploy
-------------------------------------------------
Key: MODCLUSTER-408
URL:
https://issues.jboss.org/browse/MODCLUSTER-408
Project: mod_cluster
Issue Type: Bug
Affects Versions: 1.2.8.Final
Reporter: Aaron Ogburn
Assignee: Jean-Frederic Clere
mod_cluster doesn't properly drain requests during undeploy and/or shutdown before it
sends REMOVE-APP. org.jboss.modcluster TRACE logging shows JBoss receives a STOP-APP
response indicating 0 requests and so the JBoss side thinks requests are drained.
It looks like mod_cluster only sets "BALANCER_CONTEXT_ID" when a worker is
selected by "internal_find_best_byrequests". So it doesn't count stickied
requests and allows shutdown to proceed even if stickied requests are in progress.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)