Refresh Identity Cube Refresh Required Task (which only refreshes and synchronizes the attributes, does the manager refreshes and all the other things apart from processing events)
Refresh Identity Cube - Process Events Only
But every now and then the task gets stuck, I have to terminate it and re run and post that it gets processed as expected. I am trying to get to root cause of this. One thing I found in jvm properties was -Doracle.jsbc.javaNetNio=false which I am correcting to -Doracle.jdbc.javaNetNio=false. Is this only the root cause.
also when I analyzed the Java thread dumps to see what could be other reasons I found some threads are waiting for processes and no processes are assigned to them.
There are no issues found in the log. The only thing I found is during the Java thread dump analysis that there are a few threads that are waiting and get stuck there. The status of those threads never changes.
Hey @Gurleen - question for you. Is it the “big” refresh (the one that handles all the attribute updates, sync, manager correlation, etc.) that sticks, the “process events only” on the sticks, or is it both?
Also, can you give us any insight into what lifecycle events you have configured? Are the Attribute Change events, filters, or rule-based?
All lifecycle events are Rule-based apart from just one which is Joiner based on Create Identity. Currently, I have Create, Disable, Enable, Rehire, Update, and Change Password events configured.
The first refresh task which is refresh required- handles all attribute updates, synchronizes attributes, manager correlations, role changes, and entitlement updates, and the second one which is “process events only” only processes the lifecycle events of the user.
Alright, thanks for that info! It sounds like the refresh that’s sticking from time to time is the one that’s processing events. There are a couple things I can think of trying…
Check the rule logic to make sure that there aren’t any edge-cases that might cause a subtle exception or logic loop.
Update your workflows that are launched by those events to be backgrounded immediately after launch instead of running in the foreground (using a wait="1" on the first step after the Start step is fine to accomplish this goal) and let the Perform Maintenance task handle the workflow processing a few minutes later. This should help you better track down which workflow(s) are the likely culprit, and if the Refresh itself finishes in a timely manner, you can effectively rule out your LCE rules as the culprit (no pun intended ).
Go through your workflows looking for potential provisioning events that could silently time out. A common cause of “stuck workflows” like this would be when IIQ executes a provisioning plan but doesn’t get a response back in a timely manner and the connector has a very large timeout period.
I know none of these are particularly fun exercises, but they should help get you closer to your root-cause!
).