The ticket comes from this sample of access logs:
[17/May/2017:14:44:44.156061448 -0400] conn=1104 op=1114 MOD dn="cn=repl keep alive 8,<suffix>" [17/May/2017:14:44:44.163933455 -0400] conn=1104 op=1114 RESULT err=0 tag=103 nentries=0 etime=0 csn=591d025300b400080000 [17/May/2017:14:44:46.153729882 -0400] conn=1101 op=7237 MOD dn="cn=repl keep alive 8,<suffix>" [17/May/2017:14:44:46.158657873 -0400] conn=1101 op=7237 RESULT err=0 tag=103 nentries=0 etime=0 csn=591d025300b700080000 [17/May/2017:14:44:48.156409375 -0400] conn=1101 op=7239 MOD dn="cn=repl keep alive 8,<suffix>" [17/May/2017:14:44:48.162481067 -0400] conn=1101 op=7239 RESULT err=0 tag=103 nentries=0 etime=0 csn=591d025300b800080000 [17/May/2017:14:44:48.162935161 -0400] conn=1101 op=7240 MOD dn="cn=repl keep alive 8,<suffix>" [17/May/2017:14:44:48.167485347 -0400] conn=1101 op=7240 RESULT err=0 tag=103 nentries=0 etime=0 csn=591d025300b900080000
The problem is that 591d025300b7, 591d025300b8 and 591d025300b9 are generated in a row on the same supplier. This is not the expected behavior:
It should do a single update for all skipped update.
RHEL 7.3
No reproducible test case
To many updates of the keep alive entry
keep alive entry should be updated quite rarely
Metadata Update from @tbordaz: - Issue assigned to tbordaz
One possibility that can explain this behavior is that having many replica agreement processing/skipping updates to send. Then each agreements will decide to update the keep alive entry. This explanation can explain one block of updates of the keep alive entry. But the logs actually contains many of those blocks. That means that after a block of updates, the supplier receives again more than 100 updates to skip => new block of keep alive entry. etc....
Metadata Update from @tbordaz: - Custom field type adjusted to defect
Metadata Update from @mreynolds: - Issue set to the milestone: 1.3.6.0
Metadata Update from @mreynolds: - Issue set to the milestone: 1.3.7 backlog (was: 1.3.6.0)
Metadata Update from @mreynolds: - Custom field origin adjusted to None - Custom field reviewstatus adjusted to None - Issue set to the milestone: 1.4.2 (was: 1.3.7 backlog)
Metadata Update from @vashirov: - Issue set to the milestone: 1.4.4 (was: 1.4.2)
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/2325
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 - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.