[
https://issues.apache.org/jira/browse/KAFKA-5241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17907268#comment-17907268
]
Matthias J. Sax commented on KAFKA-5241:
----------------------------------------
Thanks for your comment. As discussed, it's not the exact some issue you
observe and this ticket reports.
Thanks for filing a new ticket for the issue you discovered:
https://issues.apache.org/jira/browse/KAFKA-18168
(Replying here, if anybody reads your comment, so close the loop.)
> GlobalKTable does not checkpoint offsets after restoring state
> --------------------------------------------------------------
>
> Key: KAFKA-5241
> URL: https://issues.apache.org/jira/browse/KAFKA-5241
> Project: Kafka
> Issue Type: Bug
> Components: streams
> Affects Versions: 0.10.2.1
> Reporter: Tommy Becker
> Assignee: Tommy Becker
> Priority: Minor
> Fix For: 0.10.2.2, 0.11.0.0
>
>
> I'm experimenting with an application that uses a relatively large
> GlobalKTable, and noticed that streams was not checkpointing its offsets on
> close(). This is because although
> {{org.apache.kafka.streams.processor.internals.GlobalStateManagerImpl#restoreState}}
> updates the checkpoint map, the actual checkpointing itself is guarded by a
> check that the offsets passed from the {{GloablStateUpdateTask}} are not
> empty. This is frustrating because if the topic backing the global table is
> both large (therefore taking a long time to restore) and infrequently
> written, then streams rebuilds the table from scratch every time the
> application is started.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
