Summary: MMR: Supplier does not respond anymore after many operations (deletes)
https://bugzilla.redhat.com/show_bug.cgi?id=329951
Backend thread updating RUV and thread updating VLV index could cause a deadlock on
vlvSearchList_lock and the libdb page.
------- Additional Comments From nhosoi(a)redhat.com 2007-10-18 17:29 EST -------
Created an attachment (id=231611)
--> (
https://bugzilla.redhat.com/attachment.cgi?id=231611&action=view)
cvs diffs
Files:
plugins/replication/repl5_plugins.c
plugins/replication/repl5_replica.c
slapd/slapi-private.h
slapd/back-ldbm/ldbm_add.c
slapd/back-ldbm/ldbm_delete.c
slapd/back-ldbm/ldbm_modify.c
slapd/back-ldbm/ldbm_modrdn.c
Description: introduce OP_FLAG_REPL_RUV. It's set in repl5_replica.c if the
entry is RUV. The operation should not be blocked at the backend SERIAL
lock (this is achieved by having OP_FLAG_REPL_FIXUP set in the operation flag).
But updating RUV has nothing to do with VLV, thus if the flag is set, it skips
the VLV indexing.
Test case I'm running:
Set up 2-way MMR (Master 1 and 2)
Set purge delay: nsds5ReplicaPurgeDelay: 600
Import an LDIF file on Master 1
Initialize the replica (Master 2) on Master 1
Create browsing indexes on both Master 1 and 2
Then, I started running following test tools:
ldclt -D "cn=Directory manager" -w <passwd> -p <port> -e add -e
random -b
ou=Payroll,dc=example,dc=com -f uid=test_XXXX -v -q -n 2 -N 3600 -r 1000 -R
2999 -I 68 -e inetOrgPerson -e imagesdir=<images_dir>
ldclt -D "cn=Directory manager" -w <passwd> -p <port> -e delete -e
random -b
ou=payroll,dc=example,dc=com -f uid=test_XXXX -v -q -n 2 -N 3600 -r 1000 -R
2999 -I 32 -e inetOrgPerson -e imagesdir=<images_dir>
ldclt -D "cn=Directory manager" -w <passwd> -p <port> -e
attreplace=sn:a_random_sn_XXXX -e random -b ou=payroll,dc=example,dc=com -f
uid=test_XXXX -v -q -n 2 -N 3600 -r 1000 -R 2999 -I 32
So far, it's been running for 2 hours with occasional checks on the browser
using VLV/brousing index.