Replication lag improvement
WHAT is this pull request doing?
Before this we only counted data written to the follower socket as lag, we didn't count the data in the "action queue" of the follower.
This will change so we count data written to the action queue.
HOW can this pull request be tested?
Run follower specs
CLA Assistant Lite bot:
Thank you for your submission, we really appreciate it. Like many open-source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution. You can sign the CLA by just posting a Pull Request Comment same as the below format.
I have read the CLA Document and I hereby sign the CLA
You can retrigger this bot by commenting recheck in this Pull Request
hmm @dentarg, cla assistant skipped on my pr here, but not here...
@kickster97 Hmm, I wonder if skipping for COLLABORATOR too would help, reading https://stackoverflow.com/questions/63188674/github-actions-detect-author-association it sounds like it. I can experiment some.
I think (hope) the CLA workflow behaves better now going forward. Closing/re-opening didn't really work as I expected, the workflow only ran on the close event: https://github.com/cloudamqp/lavinmq/actions/workflows/cla.yml?query=branch%3Areplication-lag-improvement – I unlocked this PR with the GitHub CLI and also created https://github.com/cloudamqp/lavinmq/pull/654
This will also count all data that needs to be sent as lag, not only "message data" (i.e. it counts filename length etc too).
This will also count all data that needs to be sent as lag, not only "message data" (i.e. it counts filename length etc too).
Maybe it should be changed to only count message data.
This will also count all data that needs to be sent as lag, not only "message data" (i.e. it counts filename length etc too).
Maybe it should be changed to only count message data.
Is it not more accurate if we count all data? Why would we only want to count message data?