[ 
https://issues.apache.org/jira/browse/KAFKA-8755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16909249#comment-16909249
 ] 

Chris Pettitt commented on KAFKA-8755:
--------------------------------------

Also, I'll fix up the test a bit. It fails in the non optimized case too 
because we happen to be completely caught up and no restore occurs (thus, the 
start offset is not touched in the test). Also, the start offset needs to be 
volatile because it is being written from one thread and read from another with 
no obvious synchronization between the two.

> Stand-by Task of an Optimized Source Table Does Not Write Anything to its 
> State Store
> -------------------------------------------------------------------------------------
>
>                 Key: KAFKA-8755
>                 URL: https://issues.apache.org/jira/browse/KAFKA-8755
>             Project: Kafka
>          Issue Type: Bug
>          Components: streams
>    Affects Versions: 2.4.0
>            Reporter: Bruno Cadonna
>            Assignee: Chris Pettitt
>            Priority: Major
>              Labels: newbie
>         Attachments: StandbyTaskTest.java
>
>
> With the following topology:
> {code:java}
> builder.table(
>     INPUT_TOPIC, 
>     Consumed.with(Serdes.Integer(), Serdes.Integer()), 
>     Materialized.<Integer, Integer, KeyValueStore<Bytes, byte[]>>as(stateName)
> )
> {code}
> and with topology optimization turned on, Kafka Streams uses the input topic 
> {{INPUT_TOPIC}} as the change log topic for state store {{stateName}}. A 
> stand-by task for such a topology should read from {{INPUT_TOPIC}} and should 
> write the records to its state store so that the streams client that runs the 
> stand-by task can take over the execution of the topology in case of a 
> failure with an up-to-date replica of the state.
> Currently, the stand-by task described above reads from the input topic but 
> does not write the records to its state store. Thus, after a failure the 
> stand-by task cannot provide any up-to-date state store and the streams 
> client needs to construct the state from scratch before it can take over the 
> execution.
> The described behaviour can be reproduced with the attached test.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

Reply via email to