On Mon, Jan 21, 2019 at 03:23:55PM +0000, h.b.furuseth@usit.uio.no wrote:
On 20.01.2019 19:52, Hallvard Breien Furuseth wrote:
Can cn=config have 2 lock levels? That fixes this ITS (my ldapwhoami hang) without introducing cn=config failures.
The outer lock serializes cn=config ops including the indexer. Other ops do not lock it. The inner lock blocks slapd like cn=config does now, and should only be held briefly. Always hold the outer lock when taking the inner lock.
Correction again: while taking and holding the inner lock. Except non-config ops.
Except there are no locks as you know being the author of parts of code that deals with what I'm about to outline anyway:
Whenever a cn=config op is about to be processed, a pause is requested. That tells worker threads to stop picking up new work and waits until they're all quiet. The indexing task is run by one of these worker threads.
Some long-running processes (syncrepl) will regularly check to see if they should pause as well: https://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=servers/sl...
Handling things in a similar way might be an option if we could survive anything changing in cn=config while we yield. That might be a big "if" to implement, though.