mjsax commented on code in PR #13292:
URL: https://github.com/apache/kafka/pull/13292#discussion_r1132987512
##########
streams/src/main/java/org/apache/kafka/streams/processor/internals/InternalTopologyBuilder.java:
##########
@@ -1293,12 +1306,16 @@ private void setRegexMatchedTopicToStateStore() {
private <S extends StateStore> InternalTopicConfig
createChangelogTopicConfig(final StateStoreFactory<S> factory,
final String name) {
- if (factory.isWindowStore()) {
+ if (factory.isVersionedStore()) {
+ final VersionedChangelogTopicConfig config = new
VersionedChangelogTopicConfig(name, factory.logConfig());
+ config.setMinCompactionLagMs(factory.historyRetention());
Review Comment:
> Would you prefer passing factory.historyRetention() into the constructor
and setting it there? I can refactor WindowedChangelogTopicConfig as well if so.
Yes, I think it would be cleaner this way.
> Nope, the changelog topic for versioned stores is only compacted, so
delete.retention.ms is unused. (In contrast to the windowed changelog topic
case, where both compaction and retention-based deletion are enabled)
`delete.retetion.ms` is not for retention based topics, but it's for
compacted topic -- it defines how long tombstones are retained if a tombstone
is the last message for a key -- ie, a tombstone marks a "soft delete" and is
preserved for a while, but not directly removed when compaction runs. The goal
is to ensure that a potentially offline consumer does not miss a tombstone,
what would lead to a "data leak" as it might never cleanup a record.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
