Description of problem: When nsslapd-changelogtrim-interval is changed, it doesn't take effect immediately. How reproducible: always Steps to Reproduce: [1] Setup DS using "dc=example,dc=com" [2] Create the changelog [3] Set the max entries, and changelog trim interval dn: cn=changelog5,cn=config changetype: modify replace: nsslapd-changelogmaxentries nsslapd-changelogmaxentries: 5 - replace: nsslapd-changelogtrim-interval nsslapd-changelogtrim-interval: 15 [4] Enable replication for "dc=example,dc=com" [5] Turn on replication logging dn: cn=config changetype: modify replace: nsslapd-errorlog-level nsslapd-errorlog-level: 8192 [6] Add 10 entries to "dc=example,dc=com" [7] Sleep for 15 seconds [8] Grep the error log for "changes from the changelog" Actual results: Next trim starts only after current trim is finished (notice the timestamps) [13/Jan/2015:00:13:23 +0100] NSMMReplicationPlugin - changelog program - cl5GetOperationCount: found DB object 7f072400df50 [13/Jan/2015:00:18:16 +0100] - Trimmed 5 changes from the changelog Expected results: Trimming thread should be notified that config was updated.
Per 389-ds-base ticket triage, commented as:
Mark thinks it might be fixed. We should also investigate the "no-trim->trim" case.
So far I think Mark may be correct. I've not been able to reproduce this.
attachment ticket48007_test.py
Replying to [comment:6 firstyear]:
So far I think Mark may be correct. I've not been able to reproduce this. With a small change to your test I can reproduce it: {{{ --- ticket48007_test.py 2016-05-09 22:32:06.000000000 -0400 +++ ticket48007_2_test.py 2016-05-10 09:00:59.043000000 -0400 @@ -116,7 +116,7 @@ immediately. """ # Pause replication - topology.master1.replica.pause(topology.m1_c1_agmt) + #topology.master1.replica.pause(topology.m1_c1_agmt) # turn on repl logging topology.master1.config.loglevel((LOG_REPLICA,), 'error')
@@ -124,10 +124,10 @@ # Until we do https://fedorahosted.org/389/ticket/48820, we have to make do: mod = [ (ldap.MOD_REPLACE, 'nsslapd-changelogmaxentries', '5'), - (ldap.MOD_REPLACE, 'nsslapd-changelogmaxentries', '15'), + (ldap.MOD_REPLACE, 'nsslapd-changelogtrim-interval', '15'), ] topology.master1.modify_s(DN_CHANGELOG, mod) - topology.master1.replica.resume(topology.m1_c1_agmt) + #topology.master1.replica.resume(topology.m1_c1_agmt)
# Add entries for i in range(1,21):
}}}
Ahhhh excellent. With that, I'll be able to work from there. Thank you for spotting my mistake.
I can reproduce "getting the change log to trim" but in my tests, it appears that the moment I set the new trim time, it's taking effect immediately, and correctly. I think this is actually not an issue, and the difference in log times is a co-incidence.
I would like to close this as "not a bug" if that's okay with you, but I am happy to discuss it more if you like. Do you still want the test case that proves it's not an issue?
It's been a long time since this issue was raised. I can not reproduce it, and it seems to work correctly. I'm closing it as a result.
Metadata Update from @firstyear: - Issue assigned to firstyear - Issue set to the milestone: 1.3.6.0
Metadata Update from @mreynolds: - Custom field component adjusted to None (was: Replication - General) - Custom field reviewstatus adjusted to review - Custom field version adjusted to None - Issue close_status updated to: None (was: Invalid)
Metadata Update from @mreynolds: - Custom field component adjusted to Replication (was: None) - Issue close_status updated to: invalid
Ack to test case :)
Metadata Update from @firstyear: - Custom field reviewstatus adjusted to ack (was: review)
CI Test
751446440..03df576c8 master -> master
92c56e903..2ffdac295 389-ds-base-1.3.7 -> 389-ds-base-1.3.7
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/1338
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: invalid)