Bug 813157 - Replication problems:when you create a HUB replica and it modified to Supplier then the RUV/replica id details were not updated in the db/memory
Summary: Replication problems:when you create a HUB replica and it modified to Suppli...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: 389
Classification: Retired
Component: Replication - General
Version: 1.2.0
Hardware: ia64
OS: Other
unspecified
high
Target Milestone: ---
Assignee: Rich Megginson
QA Contact: Chandrasekar Kannan
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-04-17 06:02 UTC by rajendra
Modified: 2015-01-04 23:51 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-05-21 21:10:05 UTC


Attachments (Terms of Use)
The attachment has having in details description of the problem and reproduce steps (174.31 KB, application/octet-stream)
2012-04-17 06:02 UTC, rajendra
no flags Details

Description rajendra 2012-04-17 06:02:54 UTC
Created attachment 577884 [details]
The attachment has having  in details description of the problem and reproduce steps

Description of problem:

We have noticed two problems in the multiimaster replication environment of 389-1.2.0 code Base.  Here are the details below.
Problem 
=========
When the replica is modified (role change from HUB to Supplier), the replica id is updated from 65535 to newly given replica id (Ex: 15151) in the dse.ldif file. But the RUV entry in the db/memory still having the old replica id (i.e 65535 ) instead of newly provided replica id. This caused the following problems:

1.	Supplier and consumer still having the old replica ID (65535).
2.	The replication to the consumer always starts from the Min CSN and   supplier pushes all the entries from starting (If an entry is already replicated, the consumer just ignores it). Hence you can notice multiple log entries for a single operation in the access log. 
3.	Since the replication to consumer always starts from Min CSN, the new entries get replicated only after processing all old entries which would lead to delay in replication of new entries.

Kindly refer the attached document for more details .

Version-Release number of selected component (if applicable):

389-1.2.0 code Base.  

How reproducible:

Kindly refer the Attached document 


Actual results:

1) When the replica is modified (role change from HUB to Supplier),  the  Supplier and consumer still having the old replica Id insted of newly creaed Replica id in the db/memory.

2) Noticed multiple logs for single MOD operation in Access log.

Expected results:

1) When the replica is modified (i.e Role change from HUB to Supplier), the RUV entry in the db/memory needs to be updated with modified replica Id (i.e which is Supplier replica id)

2) There should not be multiple entries for single MOD operation in access logs

Comment 1 Rich Megginson 2012-04-17 13:18:13 UTC
Upstream ticket:
https://fedorahosted.org/389/ticket/341

Comment 2 Noriko Hosoi 2012-04-19 20:44:15 UTC
Did you have a chance to see this bug 750425 filed by Jyoti ranjan das (jyoti-ranjan.das)?

https://bugzilla.redhat.com/show_bug.cgi?id=750425

The fix is in 389-ds-base-1.2.10 and newer.

Is it possible to try the reproducer steps with the version?

Comment 3 Noriko Hosoi 2012-05-21 21:10:05 UTC
(In reply to comment #2)
> Did you have a chance to see this bug 750425 filed by Jyoti ranjan das
> (jyoti-ranjan.das)?
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=750425
> 
> The fix is in 389-ds-base-1.2.10 and newer.
> 
> Is it possible to try the reproducer steps with the version?

Since we did not hear from you longer than a month, we are closing this bug for now.  Please feel free to reopen it once you get the information we asked for.
Thanks.


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