Hallvard Breien Furuseth wrote:
Testing again 'subordinate' looks irrelevant. I wonder what
did in my original and bigger testcase to make it seem relevant.
On 1/19/19 6:30 PM, Howard Chu wrote:
> This is not really surprising.
I don't know these interactions well enough to be unsurprised.
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=
don't know why the ongoing indexing keeps cn=3Dconfig locked
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
> Are you suggesting the indexing task should stop if another
I'm suggesting to fail the 2nd operation if that's what it takes.
Or only hang if the user passes some LDAP control.
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=
You might make a case that background indexing on a backend shouldn't blo=
writes to unrelated parts of the cn=3Dconfig tree. The current pause desi=
easily support that, but it might be worth working on. Also it's not clea=
parts of the tree are actually unrelated. E.g., changing schema elements =
affect all backends at once.
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/