Currently there are two steps to cleaning an entire replication environment:
 Run CLEANALLRUV
 Wait for it to update all replicas - could take awhile
 Run RELEASERUV
Should add a new thread to the CLEANALLRUV code, which does the nsds50ruv searches, and once the replicas are cleaned, then it should do the RELEASERUV process automatically.
We should also log the process in the error log, like ldif2db does.
I think you will need to lock the conn object while you are using the LDAP *ld pointer. There are some thread safety issues with multiple threads accessing the same ld at the same time.
Also, do you need the conn_cancel_linger(conn); ?
Sometimes we lock the the conn when using the ld pointer, but sometimes we don't like in conn_connect() and conn_read_entry_attribute() in repl5_connection.c.
I will lock it anyway just to be safe since it's being used in a separate thread.
As for the conn linger stuff, it's "probably" not needed in this case, but I was trying to be consistent with the rest of the repl code. If we call conn_connect(), and get an existing connection, it's possible the timer might already be in effect, and it could time out before we issue our search. The timing would have to be exact for this to happen, but I don't think it hurts to cancel/set the timer in this case.
git merge ticket368
ldap/servers/plugins/replication/repl5.h | 10 +
.../servers/plugins/replication/repl5_connection.c | 26 ++
.../plugins/replication/repl5_replica_config.c | 257 +++++++++++++++++---
ldap/servers/plugins/replication/repl_extop.c | 91 +++++---
4 files changed, 316 insertions(+), 68 deletions(-)
[mareynol@localhost servers]$ git push origin master
Counting objects: 19, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (10/10), done.
Writing objects: 100% (10/10), 4.64 KiB, done.
Total 10 (delta 8), reused 0 (delta 0)
c61ee8e..507b593 master -> master
1.2.11 branch changeset:1b4b9d5/389-ds-base
Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=830340
Added initial screened field value.
Metadata Update from @mreynolds:
- Issue assigned to mreynolds
- Issue set to the milestone: 220.127.116.11
to comment on this ticket.