Bug 457329 - Make better use of cached DNA config information
Summary: Make better use of cached DNA config information
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 FDS112
TreeView+ depends on / blocked
 
Reported: 2008-07-30 22:53 UTC by Nathan Kinder
Modified: 2015-01-04 23:33 UTC (History)
2 users (show)

Fixed In Version: 8.1
Clone Of:
Environment:
Last Closed: 2009-04-29 23:05:24 UTC
Embargoed:


Attachments (Terms of Use)
CVS Diffs (11.84 KB, patch)
2008-07-30 23:12 UTC, Nathan Kinder
no flags Details | Diff

Description Nathan Kinder 2008-07-30 22:53:16 UTC
Portions of the DNA plug-in leverage the cached configuration information, while
other portions do not.  In particular, the actual configuration related to
determining the next value to assign always does an internal search on the
configuration entry instead of using the in-memory information that it already
has available.

The DNA plug-in should never need to read from it's configuration entries aside
from startup.  If a modification is made to the configuration entries directly,
we will detect that at the post-operation stage since we register a callback to
check for configuration changes.

Comment 1 Nathan Kinder 2008-07-30 23:12:50 UTC
Created attachment 313050 [details]
CVS Diffs

This fix makes the main functions that deal with allocating a new value use the
cached configuration information instead of doing an internal search for the
configuration entry.  This basically just involves using the cached information
that we already hold and eliminating the internal search, but a few other
changes were required.

Since we are using the cached information, we need to be sure to update the
cached information after we allocate a value.  This is done in
dna_notice_allocation().

I also modified the parameters passed to a few helper functions.  We used to
pass some of the config entry members separately, but it's better to just pass
the entire cached configuration entry to these functions.

There was some unnecessary code in dna_get_next_value() that would make 3
attempts at updating the "dnaNextValue" attribute in the configuration entry in
the database.  This was designed this way before a mutex was added to protect
the allocation of a new value within a range.  Now that a lock exists, these 3
attempts are not needed as it's not possible to contend with another thread in
this portion of the DNA code.  Since a mutex is used now, I also changed the
operation that updates "dnaNextValue" to use a replace operation instead of a
value delete/value add.  The delete/add was intended to detect thread
contention in case the explicit value delete failed.

One other change that was made is that the "newval" parameter that is passed
into dna_first_free_value() is no longer used to determine the next free value
to use.  Previously, the caller would pass in the value that it thinks is the
next free value, and dna_first_free_value() would verify if it was indeed free.
 If it was not free, then "newval" was modified to be the true next free value.
 The new version of dna_first_free_value() simply checks if the nextval in the
cached configuration is free, and finds the real next free value if it is not. 
This is then filled into the "newval" parameter that was passed in.

Comment 2 Nathan Kinder 2008-07-31 16:23:09 UTC
Checked into ldapserver (HEAD).  Thanks to Noriko for her review!

Checking in dna.c;
/cvs/dirsec/ldapserver/ldap/servers/plugins/dna/dna.c,v  <--  dna.c
new revision: 1.7; previous revision: 1.6
done

Comment 3 Jenny Severance 2009-04-09 19:23:21 UTC
Please add steps to verify this bug, if it is possible for QE to do. Thanks

Comment 4 Nathan Kinder 2009-04-09 21:34:12 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:24 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.