#48158 Remove cleanAllRUV task limit of 4
Closed: wontfix None Opened 9 years ago by mreynolds.

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.


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]:

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?

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.

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

7 years ago

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.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Fixed)

3 years ago

Login to comment on this ticket.

Metadata