Details

    • Type: Task Task
    • Status: Open Open (View Workflow)
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Domain Management
    • Security Level: Public (Everyone can see)
    • Labels:
      None
    • Similar Issues:
      Show 10 results 

      Description

      We need to define a clear contract between these networking services and the services that use them in order to be able to perform a graceful shutdown of remote connectors.

        Issue Links

          Activity

          Hide
          Stuart Douglas
          added a comment -

          Whatever we do here it will need to be able to be disabled, as tracking active requests will have a performance cost (although we will try and keep this as low as possible).

          I'm not sure what the best place to put the on/off switch is though. We could either do something at a server level, or else have a per-subsystem switch (so you could potentially have a situation where undertow is using graceful, however HornetQ is not). In this case if no subsystems were using it a graceful shutdown will always result in an immediate shutdown.

          Show
          Stuart Douglas
          added a comment - Whatever we do here it will need to be able to be disabled, as tracking active requests will have a performance cost (although we will try and keep this as low as possible). I'm not sure what the best place to put the on/off switch is though. We could either do something at a server level, or else have a per-subsystem switch (so you could potentially have a situation where undertow is using graceful, however HornetQ is not). In this case if no subsystems were using it a graceful shutdown will always result in an immediate shutdown.
          Hide
          Stuart Douglas
          added a comment -

          Another option would be to have a graceful-shutdown subsystem, although I am not sure if that is such a good idea.

          Show
          Stuart Douglas
          added a comment - Another option would be to have a graceful-shutdown subsystem, although I am not sure if that is such a good idea.
          Hide
          Andrig Miller
          added a comment -

          @Brian,

          Yes, I agree with you 100%.

          Andy

          Show
          Andrig Miller
          added a comment - @Brian, Yes, I agree with you 100%. Andy
          Hide
          Andrig Miller
          added a comment -

          In terms of the design for this, I think one thing that has not been discussed, at least not in the JIRA, is a graceful shutdown of a server instance in a cluster.

          It would be nice, if the other server instances in the cluster were aware of the shutdown, so messages are also stopped from being replicated, and that there is not a failure scenario initiatied, as if the server instance that is being shutdown is considered a failed node.

          Also, the thought crossed my mind about a graceful shutdown of a cluster itself (an entire server group that is also clustered).

          Show
          Andrig Miller
          added a comment - In terms of the design for this, I think one thing that has not been discussed, at least not in the JIRA, is a graceful shutdown of a server instance in a cluster. It would be nice, if the other server instances in the cluster were aware of the shutdown, so messages are also stopped from being replicated, and that there is not a failure scenario initiatied, as if the server instance that is being shutdown is considered a failed node. Also, the thought crossed my mind about a graceful shutdown of a cluster itself (an entire server group that is also clustered).
          Hide
          Stuart Douglas
          added a comment -

          My initial work on this is at
          https://github.com/stuartwdouglas/wildfly/compare/wildfly:master...stuartwdouglas:WFLY-1247

          Basically the core of it is a class called SuspendController, that manages the suspended/resumed state of the server. Subsystems can register handlers with this service that notify the controller when they are fully suspended.

          There is also a service called GlobalRequestController that is what most subsystems will actually use. Basically it registers itself with the SuspendController, and provides a simple API for entry points that deal with user requests. This controller also provides a way to limit the number of active requests running at any one time.

          This is all still very much a work in progress.

          Show
          Stuart Douglas
          added a comment - My initial work on this is at https://github.com/stuartwdouglas/wildfly/compare/wildfly:master...stuartwdouglas:WFLY-1247 Basically the core of it is a class called SuspendController, that manages the suspended/resumed state of the server. Subsystems can register handlers with this service that notify the controller when they are fully suspended. There is also a service called GlobalRequestController that is what most subsystems will actually use. Basically it registers itself with the SuspendController, and provides a simple API for entry points that deal with user requests. This controller also provides a way to limit the number of active requests running at any one time. This is all still very much a work in progress.

            People

            • Assignee:
              Stuart Douglas
              Reporter:
              Emanuel Muckenhuber
            • Votes:
              8 Vote for this issue
              Watchers:
              20 Start watching this issue

              Dates

              • Created:
                Updated: