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/