#48007 nsslapd-changelogtrim-interval is not applied immediately
Closed: wontfix Opened by nhosoi.

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.

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.

Thank you for understanding. We apologize for all inconvenience.

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

Metadata