#49266 Supplier may loop updating its keep alive entry
Opened 2 years ago by tbordaz. Modified 4 months ago

Issue Description

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.

Package Version and Platform

RHEL 7.3

Steps to reproduce

No reproducible test case

Actual results

To many updates of the keep alive entry

Expected results

keep alive entry should be updated quite rarely


Metadata Update from @tbordaz:
- Issue assigned to tbordaz

2 years ago

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

2 years ago

Metadata Update from @mreynolds:
- Issue set to the milestone: 1.3.6.0

2 years ago

Metadata Update from @mreynolds:
- Issue set to the milestone: 1.3.7 backlog (was: 1.3.6.0)

2 years ago

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)

4 months ago

Login to comment on this ticket.

Metadata