[ 
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)

Reply via email to