[
https://issues.apache.org/jira/browse/KAFKA-5241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16011360#comment-16011360
]
Tommy Becker commented on KAFKA-5241:
-------------------------------------
I should also add that it seems broken that in the absence of checkpointed
offsets in the store, the existing DB is simply opened and the contents of the
topic written to it again. I would think that without a checkpoint the
directory should be cleared and a new DB created since the contents of what is
there are unknown. Should file a separate JIRA for this?
> 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
> Priority: Minor
> Fix For: 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
(v6.3.15#6346)
