Bug 578167 - repl. of mod/replace deletes multi-valued attrs
Summary: repl. of mod/replace deletes multi-valued attrs
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: 389
Classification: Retired
Component: Replication - General
Version: 1.2.6
Hardware: All
OS: Linux
high
high
Target Milestone: ---
Assignee: Rich Megginson
QA Contact: Viktor Ashirov
URL:
Whiteboard:
Depends On:
Blocks: 434914 389_1.2.6
TreeView+ depends on / blocked
 
Reported: 2010-03-30 13:22 UTC by Rich Megginson
Modified: 2015-12-07 17:00 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-12-07 17:00:46 UTC


Attachments (Terms of Use)
0001-Bug-578167-repl.-of-mod-replace-deletes-multi-valu.patch (5.89 KB, patch)
2010-03-30 22:04 UTC, Rich Megginson
nkinder: review+
Details | Diff

Description Rich Megginson 2010-03-30 13:22:18 UTC
When a mod/replace operation is replicated, it can cause the consumer to delete the attribute instead.

Steps:
create two masters m1 and m2
set up agreements between m1 and m2 both ways
verify replication is working
stop replication (set agmt nsds5replicaupdateschedule to "2358-2359 0")
do a mod/replace of "description" with value "desc 0" to m2
wait 5 seconds
do a mod/replace of "description" with value "desc 1" to m1
wait 2 seconds
do a mod/replace of "description" with value "desc 2" to m1

restart replication (set agmt nsds5replicaupdateschedule to "0000-2359 0123456")

What should happen is that the value of the description attribute is "desc 2" since that value has the latest csn - but the bug causes the description attribute to be deleted.  A search for the attribute nscpEntryWsi shows this:
nscpEntryWsi: description;adcsn-4bb1f944000000010000;vucsn-4bb1f942000000010000;deletedattribute;deleted: description 1
nscpEntryWsi: description;vucsn-4bb1f944000000010000;deletedattribute;deleted: description 2
nscpEntryWsi: description;vucsn-4bb1f93e000000020000;deletedattribute;deleted: description 0

The deletedattribute means the attribute was deleted.

Comment 1 Andrey Ivanov 2010-03-30 19:17:25 UTC
There was sort of a similar bug - 515329. Don't know if they could be of the same type/origin.

Comment 2 Rich Megginson 2010-03-30 22:04:02 UTC
Created attachment 403607 [details]
0001-Bug-578167-repl.-of-mod-replace-deletes-multi-valu.patch

Comment 3 Rich Megginson 2010-03-30 22:54:08 UTC
To ssh://git.fedorahosted.org/git/389/ds.git
   6e839e9..c559982  master -> master

commit c559982cddbe09bad1b7717a84c7b0187111d61a
Author: Rich Megginson <rmeggins@redhat.com>
Date:   Tue Mar 30 16:01:58 2010 -0600
    Reviewed by: nkinder (Thanks!)
    Branch: HEAD
    Fix Description: The server implements a mod/replace operation as a
    mod/delete if all values, followed by a mod/add of the new values.  The
    mod/delete phase, since it removes all of the values, essentially deletes
    the attribute, so it must set the attribute deletion_csn.  This is even
    true in the case when you do a mod/replace on an attribute that doesn't yet
    exist.  We have to create an empty attribute on the deleted_attrs list with
    the deletion_csn set to the csn of the operation.  This preserves the
    semantics of the mod/replace operation.
    When doing the add phase of the mod/replace, we have to be able to
    resurrect attributes and values that may have been deleted by the mod/delete
    phase.  We can tell that we need to resurrect a deleted value in
    resolve_attribute_state_multi_valued, in the deleted_values loop, because
    the deletioncsn will be the same as the update csn, and the
    delete_priority flag will be 0.
    Platforms tested: RHEL5 x86_64
    Flag Day: no
    Doc impact: no

To ssh://git.fedorahosted.org/git/389/ds.git
   6dec072..71b5bb9  Directory_Server_8_2_Branch -> Directory_Server_8_2_Branch
commit 71b5bb925a53ecdc23c584eca9fcc4a86093b7cf
Author: Rich Megginson <rmeggins@redhat.com>
Date:   Tue Mar 30 16:01:58 2010 -0600
    Branch: Directory_Server_8_2_Branch

Comment 4 Jenny Severance 2010-05-19 20:07:26 UTC
fix verified RHEL 4

version:
redhat-ds-base-8.2.0-2010051904.el4dsrv

With Replication stopped:
On server 2: changed description to "desc 0"
On server 1: changed description to "desc 1" and then to "desc 2"

[root@jgalipea-rhel4 578167]# ldapsearch -x -h jgalipea-rhel4.idm.lab.bos.redhat.com -p 1389 -D "cn=Directory Manager" -w Secret123 -b "ou=Accounting,dc=example,dc=com" | grep description
description: desc 2
[root@jgalipea-rhel4 578167]# ldapsearch -x -h jgalipea-rhel4.idm.lab.bos.redhat.com -p 2389 -D "cn=Directory Manager" -w Secret123 -b "ou=Accounting,dc=example,dc=com" | grep description
description: desc 0


After Replication restarted:
[root@jgalipea-rhel4 578167]# ldapsearch -x -h jgalipea-rhel4.idm.lab.bos.redhat.com -p 2389 -D "cn=Directory Manager" -w Secret123 -b "ou=Accounting,dc=example,dc=com" | grep description
description: desc 2
[root@jgalipea-rhel4 578167]# ldapsearch -x -h jgalipea-rhel4.idm.lab.bos.redhat.com -p 1389 -D "cn=Directory Manager" -w Secret123 -b "ou=Accounting,dc=example,dc=com" | grep description
description: desc 2

Comment 5 Rich Megginson 2010-11-20 01:00:26 UTC
This is closely related to bz515329


Note You need to log in before you can comment on or make changes to this bug.