[ https://issues.apache.org/jira/browse/KAFKA-5241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16010417#comment-16010417 ]
ASF GitHub Bot commented on KAFKA-5241: --------------------------------------- GitHub user twbecker opened a pull request: https://github.com/apache/kafka/pull/3054 KAFKA-5241: GlobalKTable does not checkpoint offsets after restoring state Ensure checkpointable offsets for GlobalKTables are always written on close. You can merge this pull request into a Git repository by running: $ git pull https://github.com/twbecker/kafka KAFKA-5241 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/kafka/pull/3054.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #3054 ---- commit 4f7263768ef73d18cf6b90894f4a0286bc79ea14 Author: Tommy Becker <tobec...@tivo.com> Date: 2017-05-15T12:13:07Z Fix KAFKA-5241. Ensure checkpointable offsets for GlobalKTables are always written on close. ---- > 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 > > 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)