Graceful Restart with Round-robin (No. 5) - Round-Robin graceful restart is considered as the most safe cluster restart, where only one server node in the cluster is being restarted at a given time, yet it is done gracefully. The user could specify a delay for this cluster restart so that there will be a delay of the specified amount in milliseconds between the restarts of the individual nodes in the cluster. This guarantees the availability of the cluster while being restarted, but it may be inconsistent in state, if restart results in a different configuration. You could specify a maximum grace period in-case if the restart operation cannot finalize the tasks before the maximum grace period, it will force a hard restart at that moment. This restart is going to take the most time to complete out of the 4 restart options.

Hard Restart with Round-robin (No. 6) - Round-Robin hard restart guarantees the availability but it might cause some messages to be dropped. That is because the restart of the individual nodes in the cluster is not graceful. The user could specify the delay between the individual node restarts, so that there will be a delay of the specified amount in milliseconds between restarts. This restart is not safe as the first option but takes less time than that. If the user does not want to make sure the restart to be delayed for serving the already accepted messages, this restart may be used.

Gracefully Restart cluster space at once (No. 7) - Graceful restarts the cluster, but all nodes at nearly the same time. It doesn’t guarantee the availability of the cluster as all nodes are going down nearly at the same time, so there is a down time for the cluster. If the user has an option to decouple the load from the cluster and quickly wants to get the complete cluster restarted ASAP, this can be used. This is graceful meaning that, if a server node has messages in processing state, they will be finished before the restart, provided that they are finished before the maximum grace period specified. This is suitable if the restart changes the configuration, as the cluster inconsistency in configuration is nearly zero in this restart.

Hard Restart cluster space at once (No. 8) - Hard restart of the cluster is the worst option available, and should only be used if the user just needs to hard reset the complete cluster instantly without worrying about the availability nor the messages in flight (in processing). This restart is the quickest among all but should be used with care.

Gracefully Stop cluster space (No. 9) - Graceful Stop of cluster will stop all the UltraESB instances of the cluster, but will not exit the JVMs. The user could specify a maximum grace period and in-case if the stop operation cannot finalize the tasks before the maximum grace period, it will force a hard stop at that moment.

Stop cluster space (No. 10) - Stop of cluster will stop all the UltraESB instances of the cluster, but will not exit the JVMs.

Gracefully Shutdown cluster space (No. 11) - Graceful Shutdown of cluster will stop all the UltraESB instances of the cluster, and will exit the JVMs as well. The user could specify a maximum grace period and in-case if the shutdown operation cannot finalize the tasks before the maximum grace period, it will force a hard shutdown at that moment.

Shutdown cluster space (No. 12) - Shutdown of cluster will stop all the UltraESB instances of the cluster, and will exit the JVMs as well.**

Green - all the monitored entities (e.g. CPU Usage, Heap Usage, etc) of the node are operating in the normal range.

Yellow - at least one of the monitored entities have exceeded the warn threshold.

Red - at least one of the monitored entities have exceeded the critical threshold.