#47915 replication inconsistency for add/replace/delete single valued attribute
Closed: wontfix None Opened 9 years ago by lkrispen.

The following sequence of operations can cause data inconsitency between masters, but it seems to only occur with 1.2.11.15-33 and later versions of 1.2.11

on M1:

dn: uid=xxx.....
changetype: modify
add: employeenumber
employeenumber: 901

on M2:
dn: uid=xxx.....
changetype: modify
replace: employeenumber
employeenumber: 701

on M1:
dn: uid=xxx.....
changetype: modify
delete: employeenumber
employeenumber: 701

the value will not be deleted on M2


This seems to be introduce with fix for #47424, it contains the following change:

if(slapi_attr_flag_is_set(a,SLAPI_ATTR_FLAG_SINGLE) && valuesupdated &&
*valuesupdated)
< if(slapi_attr_flag_is_set(a,SLAPI_ATTR_FLAG_SINGLE) && valueset_isempty(&a->a_present_values))

all 1.3 version have the original check on valuesupdated.

With the former diff we have the deletion replicated but there's still the issue that we cannot see in the entry state the deleted attribute.

This is the code which will allow to have this again (it's present in 1.3 version as well):

entry.c:

@@ -1687,6 +1687,11 @@ entry2str_internal_put_attrlist( const S
else
{
/ There were no present values on which to place the ADCSN, so we put it on the first deleted value. /
+
+ if ( valueset_isempty(&a->a_deleted_values)) {
+ valueset_add_string ((Slapi_ValueSet *)&a->a_deleted_values, "", CSN_TYPE_VALUE_DELETED, a->a_deletioncsn);
+ }
+

With both diffs, I have deletion replicated plus this entry state in both replicas:

nscpentrywsi: vfmmoarp;adcsn-542d8e37000000010000;vdcsn-542d8e37000000010000;d
eletedattribute;deleted:

Indicating the whole attribute has been deleted.

Looks good to me. Would like to have lkrispen review this as well.

since I was involved in the discussions leading to the fix, was waiting for an other opinion, to me it also is ack

389-ds-base-1.2.11:

8512405..db60b27 389-ds-base-1.2.11 -> 389-ds-base-1.2.11

Replying to [comment:10 gparente]:

389-ds-base-1.2.11:

8512405..db60b27 389-ds-base-1.2.11 -> 389-ds-base-1.2.11
Thanks, German! Your push and closing this ticket went well. If I could ask, adding this commit string to the ticket makes others' job easier since trac generates a link to your patck in git.
commit db60b27

This fix was not enough.

Customer is hitting the core found in

https://fedorahosted.org/389/ticket/47360 (marked as duplicated of ticket 569)

which has been fixed by this changeset:

https://fedorahosted.org/389/changeset/ca02529c797903139c56bd9b8b90e8cd5bd0c3f4

We need to include this commit to consider bug as fixed.

Thanks,

German.

Pushed to 389-ds-base-1.2.11:
a605e94..340b9dc 389-ds-base-1.2.11 -> 389-ds-base-1.2.11
commit 340b9dc

Tested with valgrind as described in Ticket #47360.
Without the patch, it reported the Invalid rights and eventually the server crashed.
With the patch, no Invalid rights were reported and the server was stable.

German, is it okay to close this ticket?
Thanks!
--noriko

Yes, this ticket should be closed.

Thanks for fixing it, Noriko.

Thanks, German. Closing...

Metadata Update from @nhosoi:
- Issue assigned to gparente
- Issue set to the milestone: 1.2.11.33

7 years ago

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/1246

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Fixed)

3 years ago

Login to comment on this ticket.

Metadata