We have noticed that it is sometimes taking a verry long time for guardian to calculate paths (the ISC_LOCK guardian).
We also just saw something more strange. It seems that the ALS COMM guardian, which was managed by the ISC_LOCK guardian, became executed, although we are pretty sure no one in the control room did this. screen shot of the log is attached.
The log files and conlog report the ALS_COMM out-of-managed-mode sequence is managed->pause->exec->pause->managed. Text file is attached.
On the long times for ISC_LOCK to calculate paths, I see a log entry which suggests a transition request from LOCKING_ALS_DIFF to DARM_WFS (via LOCKING_ALS_COMM) took 12 seconds to calculate the path. Is the processing of the current state causing the delay? Log details attached.
Can you guys ellaborate on this claim of overly long path calculation time? The log you post doesn't seem to support it. From the log you posted:
2015-01-30T03:36:06.566Z ISC_LOCK [LOCKING_ALS_DIFF.run] USERMSG cleared 2015-01-30T03:36:15.586Z ISC_LOCK new request: DARM_WFS 2015-01-30T03:36:15.586Z ISC_LOCK calculating path: LOCKING_ALS_DIFF->DARM_WFS 2015-01-30T03:36:16.778Z ISC_LOCK [LOCKING_ALS_DIFF.run] USERMSG: node ALS_DIFF: NOTIFICATION 2015-01-30T03:36:27.308Z ISC_LOCK [LOCKING_ALS_DIFF.run] ALS_XARM: REQUEST => LOCKED_TRANSITION
The path calculation happens at 3:36:15.586, followed by some usercode logging about changes to the ALS_XARM request, which presumably is a subordinate of this ISC_LOCK node.
What makes you think that the ISC_LOCK is taking a long time to calculate a path? My guess is that you're confusing the manager notification about changing subordinate request with a problem with the path calculation. They're not related.