AppWorx, Dollar Universe and Sysload Community

 View Only
Expand all | Collapse all

Jobs in Process Flows did not start immediately after the predecessors completed

  • 1.  Jobs in Process Flows did not start immediately after the predecessors completed

    Posted Dec 02, 2019 01:06 PM
    Hello All,

    Product is CA Automic Applications Manager.

    I found my jobs in the Process Flows did not start right away after the predecessors job completed. Sometimes the gap can be more than a few minutes. The scenario is like:

    [In one of the process flow]
    - step 1 job
    - step 2 job
    - step 3 job
    etc

    When step 1 job completed, the step 2 job stayed in queue status. It did not start right away. The queue is at the highest priority (1) and the job in the queue is set as default (50), while there are process flows and jobs running in parallel with default priority queue (50). The official document said that the evaluation of job priority is based on (1) queue priority (2) job priority (3) date/time of request. In my case, I cannot find the root cause why there is a gap in between step 1 and step 2, also step 2 and step 3.

    Is there any log I should examine? or any configuration could contribute to this symptom? my version/release is v9.0.1_28314_28331  Build: 2833.

    Thank you,
    Charles



  • 2.  RE: Jobs in Process Flows did not start immediately after the predecessors completed
    Best Answer

    Broadcom Employee
    Posted Dec 06, 2019 02:16 PM

    Hello Charles,

    Version 9.01 of Applications Manager has been out of Support since early this year so upgrading to the latest version of Applications Manager could help resolve the issue as well as allow you to open a case with Support for further review since this type of issue may not be a queue priority issue. The issue could be some slowness in one or more threads within the RMI or Agent processes that cause the Job to be delayed to go into Running status. This type of issue generally needs a thorough review of logs and following the JOBID within the logs.

    If you would like to examine logs, you will need to first enable debug on both the Agent and the master. Debug can be enabled by doing the following:

    master debug
    Select from the GUI > Help > About Applications Manager > Debug > Check Server box > close.

    After enabling debug, debug information can be found in the $AW_HOME/log/RmiServer<timestamp>.logs of the master server or in Windows the %AW_HOME%\log\RmiServer<timestamp>.logs.

    Agent debug
    Select from the GUI > Object Admin > Administration > Agent > Edit the Agent that the Job run on > on the General Tab select Agent Debug > Apply/OK.

    After enabling debug, debug information can be found in the $AW_HOME/log/AgentService<timestamp>.logs of the master server or in Windows the %AW_HOME%\log\AgentService<timestamp>.logs.

    When reviewing both logs concurrently, you can search all instances of the search string of each Jobs JOBID to get an idea of when a Job starts and finishes and see if there are any errors, etc, that is causing the delay. However, there are many additional threads such as the mastersocketmanager thread (msm), agentsocketmanager thread (asm), refresh thread (rf) , or other threads that either may be in use or delayed for one reason or another that could be causing the delay. Without understanding what thread does what, it may be difficult to determine what is causing the delay. Hopefully this helps.

    Regards,
    Phearith Mao