Use multiple threads to process role assignment recalculations during the removal of child roles

Idea ID 2822112

Use multiple threads to process role assignment recalculations during the removal of child roles

When a child role is removed from a parent, the RRSD processes the event with a single thread and blocks all other events in the queue. When the parent has a lot of user assignments this will take a considerable time to complete as the recalculations for each user are done in series.

These recalculations seem to be independent of each other and should be good candidates for multi-threading. This would reduce the time it takes to process the event.

Tags (2)

While you cannot multi-thread removal/addition of items on an individual user, you can multithread different user operations within the driver.  The RRSD now has an option to enable multithread support.  After enabling, you either need to complete the mapping table to split threads based on OU, or add your own logic to split on another factor.

This way, if you have 100 users that need to do those massive operations, you can split out into, for example, 5 separate threads to reduce the work by a factor of 5.

Check the RRSD documentation for how to enable and configure multithreading.  As stated, the OOTB configuration is based on OU assignment, however, this may not make sense in your environment, so you may need to add a policy in the RRSD driver to handle the assignment as you see fit.

Knowledge Partner Knowledge Partner
Knowledge Partner

What is nice about the approach they took, is they provide an example of how to split by OU.  But basically all your policy in the RRSD driver needs to do is add an XML attribute disjoint-set="some value" and each value that is unique spawns a new thread.

So add a policy in the Sub-ETP that looks at the first character of the user name, and splits into disjoint-set="StartsWithA" and then disjoint-set="StartsWithB" and so on.

Or whatever you want. I.e. It is not hardcoded into the shim, it is left up to you to do whatever makes sense for your setup.  Vry clever approach.

However, specific to your request, this above by Rob and I is actually about splitting up users.  I am not sure if this applies to Role or Resource requests.  You could easily test by enabling multithreading, and then add a policy that breaks up the Resource or Role events with a disjoint-set attribute and see if that helps.

Alas, per the initial request, one Resource/Role change may affect 1000 users.  And that cannot be split up.  But the Role and Resource actions each have their own thread, so it should only block following events of the same type.


Yes, the multithreading  for individual assignments works well, but when we remove a child role from a parent role the event does not start processing  until the DirXML-DriverStorage attribute is empty and  no other events will be processed until it is finished. During the processing the thread recalculates the role assignments for each of the accounts which are assigned to the parent role one after the other. These recalculations seem to independent of each other which could make them good candidates for multithreading. The recalculations happen at a point in the RRSD after the policies are processed and the event does not get added to DirXML-DriverStorage even when multithreading is enabled.  The recalculations are expensive  for example if the recalculation takes .3 of a second and there are 8000 associations  it will hold up the queue for 40minutes. But if there were more threads working on the calculations it would take a fraction of the time.

Micro Focus Expert
Micro Focus Expert
Status changed to: Under Consideration

Under consideration for an upcoming release. We will need to evaluate efforts.

The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.