Bug 1417341

Summary: remove changelog semaphore
Product: Red Hat Enterprise Linux 7 Reporter: Noriko Hosoi <nhosoi>
Component: 389-ds-baseAssignee: Noriko Hosoi <nhosoi>
Status: CLOSED ERRATA QA Contact: Viktor Ashirov <vashirov>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.3CC: fjayalat, mreynolds, nkinder, rmeggins
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: 389-ds-base-1.3.7.5-4.el7 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-04-10 14:15:15 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: 1420851, 1467835, 1472344    

Description Noriko Hosoi 2017-01-28 02:15:48 UTC 
This bug is created as a clone of upstream ticket:
https://fedorahosted.org/389/ticket/49091

Turning an older email thread into a ticket:

in cl5_api we have a semaphore which a comment says is used to limit the number of concurrent writes, the default value is: 2

But. The semaphore is only used
- in writing an update to the changelog in write_changelog_and_ruv(), which is serialized by the backend lock and so there always will only be one
- in log_ruv_elements (when changelog is reloaded).
- ldif import
It is NOT used in changelog trimming, purging of cleaned RIDs, changelog compaction.

so, in the cases where we do use it there will be no more than two parallel updates, in cases wheer there is, or could be, heavy update contention like changelog trimming while updates are applied iz is not used.

I think it was possibly useful when writing the changelog was a real postop, so the semaphore played the role of the backend lock.

So far I only have seen problems reported  about the semaphore file when it could not be deleted, recreated and I don't see any benefit in keeping it.
Comment 3 Viktor Ashirov 2018-01-02 15:36:24 UTC 
Build tested:
389-ds-base-1.3.7.5-11.el7.x86_64

Replication acceptance tests passed, marking as VERIFIED, SanityOnly.
Comment 6 errata-xmlrpc 2018-04-10 14:15:15 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:0811