#532 RUV is not getting updated for both Master and consumer
Closed: Fixed None Opened 7 years ago by jyotidas81.

Hi,

Ruv is not getting updated properly when changing the replica role from the Admin server GUI. Please find the reproducer details below.

Reproducer:

Step-1: Create two instances named as INST1 and INST2
Step-2: Register the above two instances with the Admin server
Step-3: Assign the Hub role to INST1 from the admin server GUI. Configuration tab -> replication -> userRoot -> enable the replication and assign the HUB role -> Save
Step-4: Assign the consumer role to INST2 from the admin server GUI. Configuration tab -> replication -> userRoot -> enable the replication and assign the consumer role -> Save
Step-5: Change the role for INST1 from Hub to Master from Admin Server GUI. Configuarion tab-> replication -> userRoot > enable the Single Master check box and provide the appropriate replica id -> Save

Check the RUV

RUV:

dn: nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,dc=asiapacific,dc=hpqcorp,dc=net
objectClass: top
objectClass: nsTombstone
objectClass: extensibleobject
nsds50ruv: {replicageneration} 50b5024c0000ffff0000
dc: asiapacific
=====

Step-6: Create a replication agreement between the INST1 and INST2. Checked the RUV.There is no change here in the RUV

RUV:

dn: nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,dc=asiapacific,dc=hpqcorp,dc=net
objectClass: top
objectClass: nsTombstone
objectClass: extensibleobject
nsds50ruv: {replicageneration} 50b5024c0000ffff0000
dc: asiapacific
=====

Step-7: Add an entry to the INST1 and check the RUV

RUV in INST1:

dn: nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,dc=asiapacific,dc=hpqcorp,dc=net
objectClass: top
objectClass: nsTombstone
objectClass: extensibleobject
nsds50ruv: {replicageneration} 50b5024c0000ffff0000
nsds50ruv: {replica 65535 ldap://dirsrv12.asiapacific.hpqcorp.net:2
389} 50b506150000ffff0000 50b506150000ffff0000
dc: asiapacific
nsruvReplicaLastModified: {replica 65535 ldap://dirsrv12.asiapacifi
c.hpqcorp.net:2389} 50b50615

As you can see here, RUV in the INST1 which is a supplier is having the replica id 65535 even after given a proper id during role change and below in the INST2 RUV which is a consumer here it’s max CSN is not getting updated in the RUV. Could you please give your insight to this problem?. Please note that it is being reproduced in the latest version of 389 directory server i.e. 1.2.15

RUV in INST2:

dn: nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,dc=asiapacific,dc=hpqcorp,d
c=net
objectClass: top
objectClass: nsTombstone
objectClass: extensibleobject
nsds50ruv: {replicageneration} 50b5024c0000ffff0000
nsds50ruv: {replica 65535 ldap://dirsrv12.asiapacific.hpqcorp.net:2
389} 50b506150000ffff0000
dc: asiapacific
nsruvReplicaLastModified: {replica 65535 ldap://dirsrv12.asiapacifi
c.hpqcorp.net:2389} 50b50616


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!

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

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 !!!

Metadata Update from @jyotidas81:
- Issue assigned to mreynolds
- Issue set to the milestone: 1.3.1

3 years ago

Login to comment on this ticket.

Metadata