The DNA plug-in currently shares a single mutex to protect the generation of new values across all configured ranges. While this approach is safe, it can cause excessive thread contention if you have multiple managed ranges configured. Let's take the scenario where you have two managed ranges configured. One range is for the "uidNumber" attribute for "objectclass=posixAccount" entries, and the other range is for the "gidNumber" attribute for "objectclass=posixGroup" entries. With a single shared lock, a thread that is handling an operation to add a new group would be blocked by another thread that is trying to add a new entry. There is no need for these threads to block each other, as they will each be using a new value from separate ranges. A better approach would be to create a mutex as a part of each cached configuration object. We have one cached configuration object per configured range. When we load the configuration, we could create the mutexes and store them with the rest of the configuration. With this approach, a thread would only need to lock the range that it is getting a new value from, which would not block threads working with other configured ranges. The attached diffs implement this approach.
Created attachment 312827 [details] CVS Diffs
Checked into ldapserver (HEAD). Thanks to Noriko for her review! Checking in ldap/servers/plugins/dna/dna.c; /cvs/dirsec/ldapserver/ldap/servers/plugins/dna/dna.c,v <-- dna.c new revision: 1.6; previous revision: 1.5 done
Please add steps to verify thsi bug. Thanks
This fix is a code optimization, and is not verifiable by QE. Marking as VERIFIED.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHEA-2009-0455.html