Uploaded image for project: 'mod_cluster'
  1. mod_cluster
  2. MODCLUSTER-596

mod_cluster stop/stop-context operations do not send STOP-* in when session draining was unsuccessful

XMLWordPrintable

      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.

      • stop() or stop-context is called
      • Disable creating any new session by sending DISABLE-APP command to balancer
      "context" => {"/clusterbench" => {
                              "requests" => 0,
                              "status" => "disabled"
                          }}
      
      • Session drain
      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
      2017-05-10 09:26:05,081 WARN  [org.jboss.modcluster] (management-handler-thread - 1) MODCLUSTER000025: Failed to drain 1 remaining active sessions from default-host:/clusterbench within 10.0 seconds
      

      Issue

      • Stop-app should be sent to balancer to stop context/node, but node/context stays disabled. This happens even if session drain is successful.
        "context" => {"/clusterbench" => {
                                "requests" => 0,
                                "status" => "disabled"
                            }}
        

              rhn-engineering-rhusar Radoslav Husar
              rhn-engineering-rhusar Radoslav Husar
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated:
                Resolved: