Bug 456968 - DNA plug-in should use separate locks for each managed range.
Summary: DNA plug-in should use separate locks for each managed range.
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: 389
Classification: Retired
Component: Server - DNA Plug-in
Version: 1.1.1
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Nathan Kinder
QA Contact: Chandrasekar Kannan
URL:
Whiteboard:
Depends On:
Blocks: 249650 FDS1.2.0
TreeView+ depends on / blocked
 
Reported: 2008-07-28 22:41 UTC by Nathan Kinder
Modified: 2015-01-04 23:33 UTC (History)
2 users (show)

Fixed In Version: 8.1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-04-29 23:05:15 UTC
Embargoed:


Attachments (Terms of Use)
CVS Diffs (2.77 KB, patch)
2008-07-28 22:41 UTC, Nathan Kinder
no flags Details | Diff

Description Nathan Kinder 2008-07-28 22:41:06 UTC
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.

Comment 1 Nathan Kinder 2008-07-28 22:41:06 UTC
Created attachment 312827 [details]
CVS Diffs

Comment 2 Nathan Kinder 2008-07-30 18:18:02 UTC
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

Comment 3 Jenny Severance 2009-04-09 19:21:49 UTC
Please add steps to verify thsi bug. Thanks

Comment 4 Nathan Kinder 2009-04-09 21:34:27 UTC
This fix is a code optimization, and is not verifiable by QE.  Marking as VERIFIED.

Comment 5 Chandrasekar Kannan 2009-04-29 23:05:15 UTC
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


Note You need to log in before you can comment on or make changes to this bug.