Affects Release version(s): 1

Error Message :
No error message.

Patch level detected:Unijob 1.4.0
Product Version: Unijob 1.4.5

Description :When an alert message (engine or IO alert) is sent, it takes significantly more time when Unijob is stopping than when it is starting.

Cause type:
By design
Root Cause: This is a normal behavior. Please see in section Solution for more explanation.

OS: All
OS Version: ALL OS

When starting Unijob, the process below is followed. Therefore, the sending of an alert message is faster.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Minimum cycle time to send alerts(SIO_ALM_CYCLE): On startup, UniJob loads its Alerting Rules from UVMS. If the cycle time is set at 0, alerts will be sent immediately. Otherwise, alerts are accumulated during the cycle time and then sent (every 10 s by default).
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


When stopping Unijob, the process below is followed. Therefore, the sending of an alert message is slower.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Expected UniJob heartbeat frequency(ALM_CYCLE_TIME): UniJob sends a "heartbeat" signal to UVMS to confirm its functioning when there are no alerts. Default time: 60 s. If UVMS doesn’t receive either an Alert or a heartbeat within this time, it will wait another half cycle and then declare UniJob communication "failed". Example: the default cycle is 60 s, so if there are no alerts or heartbeat for 90 s, UVMS will set the UniJob status as "Failed" in the Node List.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Fix Status: No Fix

Workaround :
N/A