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/
