Bug 2225168

Summary: Large update of a group can exhaust workers and the LDAP server appears unresponsive
Product: Red Hat Enterprise Linux 8 Reporter: thierry bordaz <tbordaz>
Component: 389-ds-baseAssignee: thierry bordaz <tbordaz>
Status: ASSIGNED --- QA Contact: LDAP QA Team <idm-ds-qe-bugs>
Severity: high Docs Contact:
Priority: high    
Version: 8.7CC: idm-ds-dev-bugs, jonmoore, shobbs, tmihinto, vashirov
Target Milestone: rcKeywords: Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description thierry bordaz 2023-07-24 13:05:30 UTC 
Description of problem:
When memberof plugin is enabled, an update of a group can trigger many nested updates of its members. The value of 'memberof' is changed in those members. As a consequence many database pages associated to the index 'memberof' are held (write) by the parent TXN (update of the group).

Any search request, that need access to those pages (i.e. filter contains (memberof=cn=my_group,dc=com)) is stuck until the update TXN commits.

If the number of such searches requests is as high as the number of workers, all workers may be busy+locked until the TXN commits. During that time the server may receive new requests that will not be processed until the TXN commits. As a consequence the LDAP server appears unresponsive.


Version-Release number of selected component (if applicable):
All versions RHEL7/8/9


How reproducible:
Systematically. See next update


Actual results:
The server becomes unresponsive


Expected results:
The server should stay responsive