Re: (ITS#8958) 2nd cn=config update blocks slapd while adding subordinate index

[ondra@mistotebe.net]

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/slapd/syncrepl.c;hb=HEAD#l1572

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.

-- 
OndÅ?ej Kuzník
Senior Software Engineer
Symas Corporation                       http://www.symas.com
Packaged, certified, and supported LDAP solutions powered by OpenLDAP