[Fedora-directory-devel] Please review: [Bug 329951] MMR: Supplier does not respond anymore after many operations (deletes)

[Noriko Hosoi]

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 at 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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-directory-devel/attachments/20071018/690d42b8/attachment.bin>