Page History

...

• Enhance log compaction to support more than just offset comparison, so the insertion order isn't always dictating which records to keep (in effect, allowing for a form of OCC);
• The current behavior should remain as the default in order to minimize impact on already existing clients and avoid any migration efforts;
• Add new Kafka configuration "log.cleaner.compaction.strategy" to toggle the compaction strategy to this approach;
• Add new Topic configuration "compaction.strategy" representing the same as above, with reserved values "offset" and "timestamp";
• The default value of these configurations should be "offset", which represents the previous behavior;
• When this configuration is set to "timestamp", then the record timestamp will be used to determine which record to keep, in a 'keep-highest' approach;
• When this configuration is set Specifically changing this to anything other than "offset" will cause " or "timestamp", then the record headers to be are scanned for a key matching this value. If this header is found, and its value is a "long", then this value will be used to determine which record to keep, in a 'keep-highest' approach;
• When both records being compared contain a matching "compaction value", then the record with the highest offset will be kept;

• When both records being compared do not have a "compaction value" at all, then the record with the highest offset will be kept;

• When only one of the records being compared has a "compaction value", then this record is kept (as the other is considered to be anomalous);

...