kafka-jira mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matthias J. Sax (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (KAFKA-6035) Avoid creating changelog topics for state stores that are directly piped to a sink topic
Date Fri, 26 Jan 2018 21:54:00 GMT

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

Matthias J. Sax commented on KAFKA-6035:

It is best practice to assign JIRAs before starting to work on them (it's actually ok, to
assign if you plan to work on it). If you start working, you should update the ticket to
"work in progress". If you open a PR, update to "patch available". This helps to avoid conflicts.

[~Yohan123]: Did you start to work on a PR already? If not, it might be most efficient for
the project as a whole, to not repeat the work [~jeyhunkarimov] put into the existing PR

But I leave it up to you to settle on something.

> Avoid creating changelog topics for state stores that are directly piped to a sink topic
> ----------------------------------------------------------------------------------------
>                 Key: KAFKA-6035
>                 URL: https://issues.apache.org/jira/browse/KAFKA-6035
>             Project: Kafka
>          Issue Type: Sub-task
>          Components: streams
>            Reporter: Guozhang Wang
>            Assignee: Richard Yu
>            Priority: Major
> Today Streams make all state stores to be backed by a changelog topic by default unless
users overrides it by {{disableLogging}} when creating the state store / materializing the
KTable. However there are a few cases where a separate changelog topic would not be required
as we can re-use an existing topic for that. This ticket summarize a specific issue that can
be optimized:
> Consider the case when a KTable is materialized and then sent directly into a sink topic
with the same key, e.g.
> {code}
> table1 = stream.groupBy(...).aggregate("state1").to("topic2");
> {code}
> Then we do not need to create a {{state1-changelog}} but can just use {{topic2}} as its

This message was sent by Atlassian JIRA

View raw message