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/