Bug 457329
| Summary: | Make better use of cached DNA config information | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Retired] 389 | Reporter: | Nathan Kinder <nkinder> | ||||
| Component: | Server - DNA Plug-in | Assignee: | Nathan Kinder <nkinder> | ||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Chandrasekar Kannan <ckannan> | ||||
| Severity: | low | Docs Contact: | |||||
| Priority: | low | ||||||
| Version: | 1.1.1 | CC: | benl, jgalipea | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | 8.1 | Doc Type: | Bug Fix | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2009-04-29 23:05:24 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 249650, 452721 | ||||||
| Attachments: |
|
||||||
|
Description
Nathan Kinder
2008-07-30 22:53:16 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.
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 Please add steps to verify this bug, if it is possible for QE to do. 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 |