Uploaded image for project: 'JBoss Enterprise Application Platform'
  1. JBoss Enterprise Application Platform
  2. JBEAP-10822

mod_cluster session draining with non-positive timeout may wait indefinitely

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Major Major
    • 7.1.0.ER2
    • 7.1.0.DR16, 7.1.0.DR17
    • mod_cluster
    • None

      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 with waittime set to 0
      Session drain

      2017-05-10 09:18:21,953 INFO  [org.jboss.modcluster] (management-handler-thread - 2) MODCLUSTER000046: Starting to drain 1 active sessions from default-host:/clusterbench in 0 seconds.

      Issue
      This should immediately fail to drain session and send stop node/context to balancer.
      However, it looks like it is waiting for session to timeout

      Context/Node is disabled on balancer

      "context" => {"/clusterbench" => {
                        "requests" => 0,
                        "status" => "disabled"
                    }}

            [JBEAP-10822] mod_cluster session draining with non-positive timeout may wait indefinitely

            Michaela Osmerova added a comment -

            Moving from verified to closed.

            Michaela Osmerova added a comment - Moving from verified to closed.

            Bogdan Sikora (Inactive) added a comment -

            Seems to be in order

            [standalone@192.168.122.206:9990 /] /subsystem=modcluster:stop(waittime=0   
{
    "outcome" => "success",
    "result" => {"session-draining-complete" => true}
}
2017-07-21 06:34:48,539 INFO  [org.jboss.modcluster] (management-handler-thread - 6) MODCLUSTER000046: Starting to drain 1 active sessions from default-host:/karel in 0 seconds.
2017-07-21 06:35:44,585 INFO  [org.jboss.modcluster] (management-handler-thread - 6) MODCLUSTER000024: All active sessions drained from default-host:/karel in 56.0 seconds

            [standalone@192.168.122.206:9990 /] /subsystem=modcluster:stop(waittime=-1
{
    "outcome" => "success",
    "result" => {"session-draining-complete" => true}
}
2017-07-21 06:37:32,148 INFO  [org.jboss.modcluster] (management-handler-thread - 6) MODCLUSTER000046: Starting to drain 1 active sessions from default-host:/karel in -1 seconds.
2017-07-21 06:38:25,469 INFO  [org.jboss.modcluster] (management-handler-thread - 6) MODCLUSTER000024: All active sessions drained from default-host:/karel in 53.3 seconds

            Bogdan Sikora (Inactive) added a comment - Seems to be in order [standalone@192.168.122.206:9990 /] /subsystem=modcluster:stop(waittime=0 { "outcome" => "success", "result" => {"session-draining-complete" => true} } 2017-07-21 06:34:48,539 INFO [org.jboss.modcluster] (management-handler-thread - 6) MODCLUSTER000046: Starting to drain 1 active sessions from default-host:/karel in 0 seconds. 2017-07-21 06:35:44,585 INFO [org.jboss.modcluster] (management-handler-thread - 6) MODCLUSTER000024: All active sessions drained from default-host:/karel in 56.0 seconds [standalone@192.168.122.206:9990 /] /subsystem=modcluster:stop(waittime=-1 { "outcome" => "success", "result" => {"session-draining-complete" => true} } 2017-07-21 06:37:32,148 INFO [org.jboss.modcluster] (management-handler-thread - 6) MODCLUSTER000046: Starting to drain 1 active sessions from default-host:/karel in -1 seconds. 2017-07-21 06:38:25,469 INFO [org.jboss.modcluster] (management-handler-thread - 6) MODCLUSTER000024: All active sessions drained from default-host:/karel in 53.3 seconds

            Radoslav Husar added a comment -

            bsikora Correct.

            Radoslav Husar added a comment - bsikora Correct.

            Bogdan Sikora (Inactive) added a comment -

            rhn-engineering-rhusar nice Indefinitely means till all session are drained, right?

            Bogdan Sikora (Inactive) added a comment - rhn-engineering-rhusar nice Indefinitely means till all session are drained, right?

            Radoslav Husar added a comment -

            You should get the proper description in the next build then:

            [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" => "Number of seconds for which to wait for sessions to drain before stopping all contexts if session draining is in effect. Negative or zero timeout value will wait indefinitely.",
            "expressions-allowed" => false,
            "required" => false,
            "nillable" => true,
            "default" => 10,
            "unit" => "SECONDS"
        }},
        "reply-properties" => {},
        "read-only" => false,
        "runtime-only" => true
    }
}

            Radoslav Husar added a comment - You should get the proper description in the next build then: [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" => "Number of seconds for which to wait for sessions to drain before stopping all contexts if session draining is in effect. Negative or zero timeout value will wait indefinitely.", "expressions-allowed" => false, "required" => false, "nillable" => true, "default" => 10, "unit" => "SECONDS" }}, "reply-properties" => {}, "read-only" => false, "runtime-only" => true } }

            Bogdan Sikora (Inactive) added a comment -

            rhn-engineering-rhusar Here?

            [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
    }
}

            Bogdan Sikora (Inactive) added a comment - rhn-engineering-rhusar Here? [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 } }

            Radoslav Husar added a comment -

            bsikora Where do you see that description? The current description says "Number of seconds for which to wait for sessions to drain before stopping the context if session draining is in effect. Negative or zero timeout value will wait indefinitely." which is correct.

            If you don't want to drain, that is configured by the startegy, not a timeout/wait time.

            Radoslav Husar added a comment - bsikora Where do you see that description? The current description says "Number of seconds for which to wait for sessions to drain before stopping the context if session draining is in effect. Negative or zero timeout value will wait indefinitely." which is correct. If you don't want to drain, that is configured by the startegy, not a timeout/wait time.

            Bogdan Sikora (Inactive) added a comment -

            That not very user friendly as description says "Timeout to wait for all contexts to stop.", IMHO -1 should do that.

            Bogdan Sikora (Inactive) added a comment - That not very user friendly as description says "Timeout to wait for all contexts to stop.", IMHO -1 should do that.

            Radoslav Husar added a comment -

            > This should immediately fail to drain session and send stop node/context to balancer.
            Actually, 0 timeout is treated as no timeout, i.e. wait indefinitely.

            Radoslav Husar added a comment - > This should immediately fail to drain session and send stop node/context to balancer. Actually, 0 timeout is treated as no timeout, i.e. wait indefinitely.

            Bogdan Sikora (Inactive) added a comment -

            rhn-engineering-rhusar Looks like it, i cannot confirm indefiniteness of the wait, but i can confirm that it wait's longer than session is able to be alive

            Bogdan Sikora (Inactive) added a comment - rhn-engineering-rhusar Looks like it, i cannot confirm indefiniteness of the wait, but i can confirm that it wait's longer than session is able to be alive

              rhn-engineering-rhusar Radoslav Husar
              bsikora Bogdan Sikora (Inactive)
              Bogdan Sikora Bogdan Sikora (Inactive)
              Bogdan Sikora Bogdan Sikora (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated:
                Resolved: