Hi,

Thank you very much for this patch!!!

I have tested this patch in my set up and observed few issues in it. Details are given below.

RUV before promoting the server:

dn: nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,dc=asiapacific,dc=hpqcorp,dc=net

objectClass: top
objectClass: nsTombstone
objectClass: extensibleobject
nsds50ruv: {replicageneration} 50b5024c0000ffff0000
dc: asiapacific

RUV after promoting same Hub to Master:

There is no change in this case in RUV.

dn: nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,dc=asiapacific,dc=hpqcorp,dc=net

objectClass: top
objectClass: nsTombstone
objectClass: extensibleobject
nsds50ruv: {replicageneration} 50b5024c0000ffff0000
dc: asiapacific

RUV after adding a entry to newly promoted Master:

Here RUV missing the URL and max CSN

dn: nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,dc=asiapacific,dc=hpqcorp,dc=net

objectClass: top
objectClass: nsTombstone
objectClass: extensibleobject
nsds50ruv: {replicageneration} 50b5024c0000ffff0000
dc: asiapacific
nsds50ruv: {replica 65535} 50b506150000ffff0000

RUV after adding the seconed element:

In this case RUV looks clean and correct.

I believe, after promoting the server the RUV should contain the proper entry. In this case, it looks same after the promotion

Regards,
Jyoti

Ok, so the ruv is missing the purl(url) after the first promotion to a master.

I just fixed this, see the new attachment.

Also, we were incorrectly adding the ruv for 65535. It should not be included, only the top master RUV should be seen(once initialized).

Please let me know how this patch works for you.

Thanks Jyoti!

revision
0001-Ticket-532-RUV-is-not-getting-updated-for-both-Maste.patch

git merge ticket532
Updating a0986e6..93b6cef
Fast-forward
ldap/servers/plugins/replication/repl5.h | 4 ++
ldap/servers/plugins/replication/repl5_plugins.c | 2 +-
ldap/servers/plugins/replication/repl5_replica.c | 38 ++++++++++++++-----
.../plugins/replication/repl5_replica_config.c | 33 ++++++++++++++++-
ldap/servers/plugins/replication/repl5_ruv.c | 10 +++---
ldap/servers/slapd/csngen.c | 13 ++++++-
ldap/servers/slapd/slapi-private.h | 2 +
7 files changed, 83 insertions(+), 19 deletions(-)

[mareynol@localhost servers]$ git push origin master
Counting objects: 27, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (14/14), done.
Writing objects: 100% (14/14), 2.42 KiB, done.
Total 14 (delta 12), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/389/ds.git
a0986e6..93b6cef master -> master

Hi,

Sorry for the late reply.

I have tested the new patch in my set up. But still i see there is some issue in this.More details are explained below.

Reproducer details:
1) There are two systems lets name them as "A.examples.com" and "B.examples.com"
system A is having the instance name Master and System B is having the instance name Hub and there is a replication agreement in between Master and Hub. RUV for Master and Hub looks like below.

For Master: replica 10 ldap://A.examples.com:389 MinCSN MaxCSN

For Hub : replica 10 ldap://A.examples.com:389 MinCSN MaxCSN

2) Now promote the Hub as Master from GUI and during promotion give the same replica id i.e. 10 as of the previous master.

3) After promotion the RUV in newly promoted Master looks like below.

For Hub : replica 10 ldap://A.examples.com:389 MinCSN MaxCSN

As we can see above there is no change seen in the RUV. In this Case the URL in the RUV should have updated with the new system details like "ldap://B.examples.com:< New port>"

I have debugged the code and got some clue. In the function "ruv_add_replica" in file repl5_ruv.c there is no logic to handle the situation like if the replica object is not null for the given ID what action needs to be taken. I have made some changes in this function to handle this situation better. The code snapshot is given below. Could you please verify the changes if it's Ok to incorporate this changes to 389 directory.

Code:

int
ruv_add_replica (RUV ruv, ReplicaId rid, const char replica_purl)
{
RUVElement* replica;

PR_ASSERT (ruv && replica_purl);

slapi_rwlock_wrlock (ruv->lock);
replica = ruvGetReplica (ruv, rid);
if (replica == NULL)
{
    replica = ruvAddReplicaNoCSN (ruv, rid, replica_purl);
}
else                ------> This else block i have added here to handle it.
{
    /* Update the URL if the replica object is not NULL */
     slapi_rwlock_unlock (ruv->lock);
     ruv_replace_replica_purl (ruv, rid, replica_purl);
}

slapi_rwlock_unlock (ruv->lock);

if (replica)
    return RUV_SUCCESS;
else
    return RUV_MEMORY_ERROR;

}

Regards,
Jyoti

Thanks Jyoti,

So you have tested this code, and it works for you?

I didn't have all the details when I worked on this last time, so I want to make sure it's working for you before I do my setup/testing again.

Thanks,
Mark

Hi Mark,

Yes, I have tested this code and it work fine for me. But I am afraid it shouldn't have side effect on any other scenario. Also, i want to know if we can handle it in better way than this.

Regards,
Jyoti

Thanks Jyoti,

Stuck on a hot issue today, but hope to investigate/work on this tomorrow. Thanks for your help.

Mark

Revision - update the purl in the RUV
0001-Ticket-532-update-purl.patch

Jyoti,

Thanks for the test patch. I did revise it a bit, and it passed all of my tests. The fix has been sent out for review.

Regards,
Mark

git merge ticket532
Updating 0d41c0b..01e3e3b
Fast-forward
ldap/servers/plugins/replication/repl5_ruv.c | 22 +++++++++++++++++-----
ldap/servers/plugins/replication/repl5_ruv.h | 5 +++++
2 files changed, 22 insertions(+), 5 deletions(-)

git push origin master
Counting objects: 15, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (8/8), done.
Writing objects: 100% (8/8), 1.19 KiB, done.
Total 8 (delta 6), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/389/ds.git
0d41c0b..01e3e3b master -> master

Replying to [comment:13 mreynolds]:

Jyoti,

Thanks for the test patch. I did revise it a bit, and it passed all of my tests. The fix has been sent out for review.

Regards,
Mark

Thanks a lot Mark !!!

Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=918708

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/532

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.