When an EXTERNAL parameter is present in the variable CA_OPR_FORK_LIST of local settings, OPR launches each EXTERNAL Message Action in a new thread. The thread remains active until completion of the external action. This produces a parallel execution of EXTERNAL commands. However, when using a DLL in the EXTERNAL action to call a perl function, the execution of the MRAs (and perl function) is sequential. Why does this happen?
This happens because the perl function is executed as part of a DLL (for example: "em_perl.dll PerlExec test_sleep"). When the perl function is called in this way, it needs to maintain a single Global stack that must be protected. Therefore, when the control is passed over to perl, it issues a lock that does not allow the function to be executed in parallel.
Thus, the perl function is running sequentially and that is why we see the MRAs being executed sequentially (in fact, they are waiting for the perl function to finish). Removing this lock can generate exceptions or memory leaks if the arguments are passed to Perl function.
Two alternatives exist to achieve parallel execution of perl commands:
- Event command Proxy usage. This field developed utility (FDU) can be used for large scale command execution. This is an scalable Windows service to intelligently control parallel executions of commands from CA NSM.
- The perl script can be called from an MRA with action=COMMAND and text=<script.pl>. This MRA will launch the command in parallel if called multiple times.