#525 Introducing a user visible configuration variable for controlling replication retry time
Closed: wontfix Opened by che29988.

At present if one of the masters goes down in multi master replication scenario, the other jdb will try to replicate , on failure it retries after 3 seconds on consecutive failures it doubles the retry time to maximum of 300 seconds and finally it retries once in 300 seconds.

It would be good if the max and min retry time interval been exposed as a configuration variable like replication timeout


this is a must have feature.

Replying to [comment:4 kimcharli]:

this is a must have feature.

I have raised the priority. But this issue is not likely to be fixed for a while.

You can force replication to happen immediately - you could write a script to do this - once a master is back up, tell the other masters to replicate to it immediately

see https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Replication-Forcing_Replication_Updates.html#Forcing_Replication_Updates-Forcing_Replication_Updates_from_the_Command_Line

git merge ticket525
Updating 0c37479..41d95f8
Fast-forward
ldap/schema/01core389.ldif | 6 +-
ldap/servers/plugins/replication/repl5.h | 6 +
.../plugins/replication/repl5_inc_protocol.c | 62 ++++-
.../plugins/replication/repl5_prot_private.h | 4 +
ldap/servers/plugins/replication/repl5_replica.c | 295 +++++++++++---------
ldap/servers/plugins/replication/repl_globals.c | 2 +
.../plugins/replication/windows_inc_protocol.c | 20 +-
7 files changed, 239 insertions(+), 156 deletions(-)

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), 3.32 KiB, done.
Total 14 (delta 12), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/389/ds.git
0c37479..41d95f8 master -> master

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

git merge ticket525
Updating 09f55fc..dde9abe
Fast-forward
ldap/servers/plugins/replication/repl5.h | 8 +-
ldap/servers/plugins/replication/repl5_replica.c | 48 +++++++++++-----
.../plugins/replication/repl5_replica_config.c | 60 +++++++++++++++++--
3 files changed, 90 insertions(+), 26 deletions(-)

git push origin master
Counting objects: 17, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (9/9), done.
Writing objects: 100% (9/9), 1.77 KiB, done.
Total 9 (delta 7), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/389/ds.git
09f55fc..dde9abe master -> master

commit dde9abef5ca71fc0557c66cabb99cb0a6f5e0332
Author: Mark Reynolds mreynolds@redhat.com
Date: Thu Feb 13 14:54:11 2014 -0500

1.3.2

01a1121..56e3a09 389-ds-base-1.3.2 -> 389-ds-base-1.3.2
commit 56e3a09e714f0b2bf38bdf92ba43242a52c748ba

1.3.1

a4a4642..b45fb44 389-ds-base-1.3.1 -> 389-ds-base-1.3.1
commit b45fb4481ad2ab7824858d418ba09428191775a4

git patch file (master) -- Fixing "Coverity 12434 Dereference before null check"
0002-Ticket-525-Replication-retry-time-attributes-cannot-.patch

Thank you for reviewing the fix, Rich.

Pushed to master:
cd35419..bbe0a99 master -> master
commit bbe0a9974c673336f42788cecaebdb46ddad03f4

Pushed to 389-ds-base-1.3.2:
c3cc56b..981c951 389-ds-base-1.3.2 -> 389-ds-base-1.3.2
commit 981c951cfc485f62f7207d42bcc563f0e50260e7

Pushed to 389-ds-base-1.3.1:
d6a57ad..4f9ec32 389-ds-base-1.3.1 -> 389-ds-base-1.3.1
commit 4f9ec32b9904a359caf6a9c2f92f1c6e107727d4

Linked to Bugzilla bug: https://bugzilla.redhat.com/show_bug.cgi?id=1064986 (''Red Hat Enterprise Linux 7'')

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

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

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)

Metadata