Background reconciliation - replica#4761
Background reconciliation - replica#4761frankgh wants to merge 7 commits intoapache:cep-45-mutation-trackingfrom
Conversation
frankgh
force-pushed
the
CASSANDRA-20378
branch
2 times, most recently
from
3e041d0 to
78aef1e
Compare
patch by Francisco Guerrero; reviewed by TBD for CASSANDRA-20378
frankgh
force-pushed
the
CASSANDRA-20378
branch
from
78aef1e to
e1eb794
Compare
|
|
||
| private static class BackgroundReconciler | ||
| { | ||
| private static final long RECONCILE_INTERVAL_MILLIS = 1_000; |
There was a problem hiding this comment.
I think should probably be a config property / hot prop
| { | ||
| private static final long RECONCILE_INTERVAL_MILLIS = 1_000; | ||
|
|
||
| private volatile boolean isPaused = false; |
There was a problem hiding this comment.
enabling/disabling should also be configurable and jmx adjustable. That said, we should log a warning if we startup with mutation tracking keyspaces, or create them at runtime and background reconciliation is disabled
| { | ||
| try | ||
| { | ||
| List<Offsets.Immutable> missing = shard.collectLocallyMissingOffsets(); |
There was a problem hiding this comment.
We need to take care to not spam nodes with the same mutation requests over and over here. Asking a node that's falling behind for multiple copies of the same mutation is going to help tip it over. Additionally, and I'm not sure to what degree this is actually a problem, but without a cool off period for new mutations here, we're going have some amount of fetches that are already on the way caused by races between mutation summary receipts and organic mutation receipt.
That said, it may be best to open a followup JIRA for these improvements instead of adding to the scope of this one.
2 participants
patch by Francisco Guerrero; reviewed by TBD for CASSANDRA-20378