Bug #18983
closed
A writeLock must never be in a read lock for LDAP repo
Added by François ARMAND over 3 years ago.
Updated over 3 years ago.
Category:
Performance and scalability
Description
In Ldap repos, we have at several places lock.readLock.use(... get ldap info... lock.writeLock.use(modify ldap))
This is broken: we could have two concurrent read, then a write which modify what should have been read by the other fiber.
- Related to Bug #18584: semaphore gurading LDAP repos are created each time added
- Status changed from New to In progress
- Target version changed from 798 to 6.1.10
- Status changed from In progress to Pending technical review
- Assignee changed from François ARMAND to Nicolas CHARLES
- Pull Request set to https://github.com/Normation/rudder/pull/3527
- Has duplicate Bug #15020: Lock access error on git when writing thousands of files during a policy generation added
- Has duplicate Bug #18892: Technique Upgrade failed with a JGit error after upgrading from 5.0.20 to 6.1.9 added
- Status changed from Pending technical review to Pending release
- Fix check changed from To do to Checked
- Status changed from Pending release to Released
This bug has been fixed in Rudder 6.1.10 and 6.2.3 which were released today.
- Related to Bug #16441: Git error at install on debian9 added
- Related to Bug #19398: Git error when deleting a node or archiving everything, and very slow git added
Also available in: Atom
PDF
Updated by 
Updated by