- UNIFYNow Forum
-
Ideas
Operation retry processing should not occur once scheduler has been stopped
Present Event Broker behaviour when the scheduler is shut down while operation lists are still executing is to invoke configured retry processing on each operation if there has been a failure in that operation. Under these circumstances a run profile operation which is forced to stop by an operator using the FIM Identity Manager console automatically starts again, and the operator is forced to stop the run profile a second time. Presumably this would have also been a third time if not for the resultant communications error which resulted:
Management Agent: Claims MA - Run Profile: Full import and full synchronization
0 of 2 Operation faulted: Operation for management agent with id 37818139-7ef0-4a70-a16a-046aff0d5226 with name Full import and full synchronization failed with result stopped-user-termination-from-wmi-or-ui - Please see the log viewer for more details.
1 of 2 Operation faulted: Operation for management agent with id 37818139-7ef0-4a70-a16a-046aff0d5226 with name Full import and full synchronization failed with result stopped-user-termination-from-wmi-or-ui - Please see the log viewer for more details.
2 of 2 Operation faulted: Operation for management agent with id 37818139-7ef0-4a70-a16a-046aff0d5226 with name Full import and full synchronization failed with result connection-failure - Please see the log viewer for more details.
Although this scenario is not limited to "start-up" operations lists, this behaviour is most likely to be a "nuisanse" in start-up conditions than anywhere else ... for instance the operator discovers a problem during start-up of the EvB scheduler, and wants to shut down all FIM operations. Turning off the scheduler is only the start ... followup actions are always required (which are tedious and sometimes unpredictable) in order to bring all EvB operations to a complete stand-still.
Although I very much doubt it, perhaps under some circumstances you might want retry to continue to work at an operation level, but more times than not this would be unwanted behaviour (you are trying to shut down ... if you wanted things to continue you would disable everything else).
Customer support service by UserEcho
This scenario has now played out dozens of times @ DEEWR, and while it's just of nuisance value to me, it will be bigger than that for operations folk who might start to panic under similar circumstances in Production.
Updated billing key.
Matt, I read this is as providing the user with an option to stop the scheduler recognizing retry configuration, and we'd just have to ignore all retries and treat failures as permanent. Do you read it the same and if so, will the current structure support it easily enough?
Just a quick update Bob - we've discussed this and agree that the use case you've described is very applicable to all environments. We would however like to maintain a certain level of choice so the administrators can choose how they want it behave - though likely with your suggestion as the future default option (which we'd like to discuss with you further at the appropriate time).
As this requires some changes to the core engine and the user interface it will be scheduled for the next feature release. If there's any questions you have or advice we can provide in the mean time, feel free to ask.
Migrated to Visual Studio Online.