Our Account Collectors run successfully for the target application. But after data collection and rule processing, collection stuck on Change Verification step and keep in Running status forever. Neither it shows any error in Aveksa Server log. We need to restart ACM to abort the collection step.
I have a feeling this was intended for RSA Support instead of the community? In all cases, we recommend reporting these kind of problems to RSA Support since they requires going through logs and maybe having a remote session to check your environment.
To speed up the process, please take a look at New Feature: Log Artifact and 000030327 - Artifacts to gather in RSA Identity Governance & Lifecycle to provide the required information and logs up front.
I wouldn't recommend restarting the application right away unless you are absolutely sure it is stuck and not doing anything in the background. Interrupting a running task by restarting the application can leave your data in a not-fully processed state.
First make sure, from the database level, that there are no active sessions related to the running task. Only if there aren't any active sessions, then yes only way to cancel some stuck running tasks is by restarting the application.
The Change Verification step may take some time to complete. It is processing watches on 444537 change requests. Stale or incorrect database statistics can cause longer SQL execution times on this step. Most likely this will complete in a few hours if you let it run. Otherwise RSA Customer Support will take a broader look at your database to understand the issue. As noted by Mostafa we will require a full artifact set to troubleshoot. For 7.1.1 and later just provide the "log artifacts", for 7.1.0 or earlier you need to supply these individually.
Of my experience with the product the above screenshot CLEARLY shows a stacktrace, and this product has a poor way of detecting those, meaning often these collections continue FOREVER.
There are many ways to tackle this type of problem, and the suggested answer of at least contacting support is probably the best recommendation.
Although because this behaviour (of not handling stack-traces correctly) I strongly urge EVERYONE to vote for the idea that allows a timeout to be set for collectors: Option to define collection duration (time out)
Even if it would cause havoc for the system to abort a collector by timeout.. it is still faster then letting the collector get stuck for, say 66hours (normal case if this happens just before a weekend) before "seeing" the problem and hence acting on the problem.
My company has set an alarm for the amount of queued collectors, but again often there is nothing you can do. Cancelling a collector doesn't work (what I know it cancels all queued items which is NOT an option) so my company also implements "restart of the server" when a stack trace occurs, and then ONLY the stuck collector gets aborted. But this method could mean you will be forced to do a full refresh next time… still worth it if you ask me.
But again best way is to fix all things causing those stack traces in your Collectors in the first place...
Yes, globally we need a way to abort collections that do not complete in a timely manner for any reason so that the agent can proceed to the next collection. Please ensure you vote for the RSA Idea.
Until that feature is implemented, we have no choice but to troubleshoot specific issues with specific collectors.
I tried to make a best guess at what the issue was from the partial screen shot of the exception, but all I can say is it is likely connection related. I recommend a case be opened so we can see the full error.
I have a feeling this was intended for RSA Support instead of the community? In all cases, we recommend reporting these kind of problems to RSA Support since they requires going through logs and maybe having a remote session to check your environment.
To speed up the process, please take a look at New Feature: Log Artifact and 000030327 - Artifacts to gather in RSA Identity Governance & Lifecycle to provide the required information and logs up front.