You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@kafka.apache.org by "Nikita Shupletsov (Jira)" <ji...@apache.org> on 2025/09/09 00:26:00 UTC
[jira] [Commented] (KAFKA-18191) StreamJoined name is not used for processor names
[ https://issues.apache.org/jira/browse/KAFKA-18191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18018945#comment-18018945 ]
Nikita Shupletsov commented on KAFKA-18191:
-------------------------------------------
I took a look and it looks like it's the expected behavior.
According to [KIP-479: Add StreamJoined config object to Join|https://cwiki.apache.org/confluence/display/KAFKA/KIP-479%3A+Add+StreamJoined+config+object+to+Join]:
{quote}{color:#172b4d}So if users wish to upgrade to 2.4 and don't provide a name for the states stores, it will continue to use the auto-generated name in 2.3. Of course, if users elect to name the state stores, they can do so via {color}{{StreamJoined#as("store name"). Naming the store}}{color:#172b4d} is recommended to pin the changelog topic names in case of any upstream topology changes.{color}
{quote}
Also the [javadoc|https://github.com/apache/kafka/blob/trunk/streams/src/main/java/org/apache/kafka/streams/kstream/StreamJoined.java#L145-L147] explicitly calls this out.
Right now I am not sure how we can change the behavior without breaking the compatibility. So I am not 100% any changes are needed.
> StreamJoined name is not used for processor names
> -------------------------------------------------
>
> Key: KAFKA-18191
> URL: https://issues.apache.org/jira/browse/KAFKA-18191
> Project: Kafka
> Issue Type: Bug
> Components: streams
> Reporter: A. Sophie Blee-Goldman
> Assignee: Nikita Shupletsov
> Priority: Major
>
> The StreamJoined#as API allows you to set a name for a stream-stream join operator. The intention is to allow one to name the stores, and therefore changelogs, resulting in an upgradeable topology, but it is a bit strange that the name isn't also used for the processors themselves.
> Of course, the stream-stream join is a bit of an edge case compared to, say, a count or filter operator, where the operator is a 1:1 mapping to the processor node and the user can name the processor exactly, because the stream-stream join operator actually results in multiple processors which each need a unique name. However, we could at least use the specified StreamJoined name as the basis for the resulting processor names, to avoid getting stuck with names like "KSTREAM-JOINTHIS-0000000004" and "KSTREAM-WINDOWED-0000000003" which are difficult to interpret and make it hard to read a topology
> Note that there is some existing precedent for this: for example with cogroups, the individual processors inherit the base name of the cogroup's aggregate operator name. For example this code
>
> {code:java}
> grouped1
> .cogroup((k, v, a) -> a + v) // wrapped 1
> .cogroup(grouped2, (k, v, a) -> a + v) // wrapped 2
> .aggregate(() -> "", Named.as("myName"), Materialized.as("store")) {code}
>
> produces processors with these names: "myName-cogroup-agg-0", "myName-cogroup-agg-1", "myName-cogroup-merge"
--
This message was sent by Atlassian Jira
(v8.20.10#820010)