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

[hyc@symas.com]

Hallvard Breien Furuseth wrote:
> Testing again 'subordinate' looks irrelevant. I wonder what I
> did in my original and bigger testcase to make it seem relevant.
>=20
> On 1/19/19 6:30 PM, Howard Chu wrote:
>> This is not really surprising.
>=20
> I don't know these interactions well enough to be unsurprised.
>=20
> It's not hard to guess that modify(olcDbIndex) might be heavy and
> had better be tested.=C2=A0 A simple test says it returns quickly.=C2=A0=
 I
> don't know why the ongoing indexing keeps cn=3Dconfig locked after
> the operation succeeded, instead of keeping something in the
> indexed DB locked.=C2=A0 I wouldn't expect others to guess that either.

modifications to cn=3Dconfig require no other threads to be active. Once =
the background indexer
starts running, its activity will of course block further cn=3Dconfig mod=
ifications until it
completes.

>> Are you suggesting the indexing task should stop if another config mod=
 comes in?
>=20
> I'm suggesting to fail the 2nd operation if that's what it takes.
> Or only hang if the user passes some LDAP control.
>=20
> I'm suggesting that config pauses should be brief.=C2=A0 Server hangs
> are bad.=C2=A0 Even a crash can be better when other load-balanced
> servers can take over.=C2=A0 Not that I'm suggesting that "fix":-)

The *server* is not hung. Only modifications to the cn=3Dconfig DB are bl=
ocked.

You might make a case that background indexing on a backend shouldn't blo=
ck
writes to unrelated parts of the cn=3Dconfig tree. The current pause desi=
gn wouldn't
easily support that, but it might be worth working on. Also it's not clea=
r which
parts of the tree are actually unrelated. E.g., changing schema elements =
could
affect all backends at once.

--=20
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/