Originally, since only 4 masters are officially supported a limit of 4 tasks seemed to make sense. However, there are different scenarios where more than 4 tasks will need to be run, and there is no real reason to limit it.
attachment 0001-Ticket-48158-Remove-cleanAllRUV-task-limit-of-4.patch
Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1219208
2eba67c..cd8614a master -> master [mareynol@localhost replication]$ git log -1 commit cd8614a75852f4d05dc76d104867542f18384416 Author: Mark Reynolds mreynolds@redhat.com Date: Wed May 6 15:08:22 2015 -0400
8e21bfb..faa14f5 389-ds-base-1.3.3 -> 389-ds-base-1.3.3 commit faa14f582a995cb57afbb602d3f8264794c3568b
644a116..04020a3 389-ds-base-1.3.2 -> 389-ds-base-1.3.2 commit 04020a3bda9f814e077740766b87b43b487db7b1
d1a86c8..0206e01 389-ds-base-1.3.1 -> 389-ds-base-1.3.1 commit 0206e01b523417e4c7315bec8b967497f130c2af
bd0c50a..b97803f 389-ds-base-1.2.11 -> 389-ds-base-1.2.11 commit b97803f9797138a0d218ea2f2c6891fe798e2fcf
if I understand it correctly set_cleaned_rid() will silently ignore a rid once the array gas reached the CLEANRIDSZ limit. so the check if(get_abort_cleanruv_task_count() >= CLEANRIDSIZ){ will never be true. shouldn't set_cleaned_rid() return an error to be logged and handled if the limit is exceeded?
Replying to [comment:6 lkrispen]:
We check for this limit and log an error in the beginning of:
replica_execute_cleanall_ruv_task() replica_cleanall_ruv_abort()
These checks are done before we call set_cleaned_rid(), and I've seen these error messages in customer logs as of very recently, so it is working correctly.
attachment 0001-Ticket-48158-cleanAllRUV-task-limit-not-being-enforc.patch
c9220fe..d774b19 master -> master commit d774b19fe6a1626cca3c92b125e56a22771bba5a Author: Mark Reynolds mreynolds@redhat.com Date: Mon May 18 14:51:55 2015 -0400
faa14f5..14e2e34 389-ds-base-1.3.3 -> 389-ds-base-1.3.3 commit 14e2e340e872051d114125242d61da062f46890c
04020a3..31f7311 389-ds-base-1.3.2 -> 389-ds-base-1.3.2 commit 31f73113fd266a72878a8d6c07f099b6a1b84e29
0206e01..35f75ce 389-ds-base-1.3.1 -> 389-ds-base-1.3.1 commit 35f75cea094460f108a2a794bb7571985d4bd24d
070037a..fd427d1 389-ds-base-1.2.11 -> 389-ds-base-1.2.11 commit fd427d1db9820ce3bb81e2b72e20caa7e35bf6f9
Metadata Update from @mreynolds: - Issue assigned to mreynolds - Issue set to the milestone: 1.2.11.33
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/1489
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: Fixed)
Login to comment on this ticket.