-
Bug
-
Resolution: Won't Do
-
Major
-
None
-
7.1.0.DR16, 7.1.0.DR17
-
None
-
User Experience
-
-
-
-
-
Cli operation description
[standalone@localhost:9990 /] /subsystem=modcluster/:read-operation-description(name=stop { "outcome" => "success", "result" => { "operation-name" => "stop", "description" => "Tell reverse proxies that all contexts on the node can't process requests.", "request-properties" => {"waittime" => { "type" => INT, "description" => "Timeout to wait for all contexts to stop.", "expressions-allowed" => false, "required" => false, "nillable" => true, "default" => 10, "unit" => "SECONDS" }}, "reply-properties" => {}, "read-only" => false, "runtime-only" => true } }
With default and non distributable context or draining strategy set to ALWAYS.
1. stop() or stop-context is called
2. Disable creating any new session by sending disable-app to balancer is called
"context" => {"/clusterbench" => { "requests" => 0, "status" => "disabled" }}
3. Session drain is triggered
2017-05-10 09:19:09,956 INFO [org.jboss.modcluster] (management-handler-thread - 1) MODCLUSTER000046: Starting to drain 1 active sessions from default-host:/clusterbench in 10 seconds.
- Session timeout is 5 minutes so it fails
Issue
At this point if someone send request with old session that no longer exist but browser still sends JSESSIONID with jvmroute set to stopping node.
Balancer will route it as he has set status to disabled and therefore any "existing" session should be routed that way. Node will take that request and
create new session(as the old one don't exist) and mark himself as session owner(jvmRoute) so any other requests will be routed and handled by this node even if node is in stopping phase.
Proposal
Node that is stopping itself with draining active sessions shouldn't became owner of any new sessions. If there is possibility owner of such session should became any other node in cluster.
- is related to
-
JBEAP-10356 mod_cluster stop/stop-context(waittime=..) attribute description is wrong
- Closed