[
https://issues.apache.org/jira/browse/KAFKA-9925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17094772#comment-17094772
]
Guozhang Wang commented on KAFKA-9925:
--------------------------------------
[~vvcephei] Thanks for getting a look into this issue.
I'm wondering if now is a good time to deprecate the `StreamsBuilder#build()`
function to let users use `build(final Properties props)` instead as a tiny
KIP. There's risk of course that the props passed in `build` is not the same as
the one passed into the `KafkaStreams` constructor. I think we can remember the
reference of the Props when building the topology, and then at construction if
we found they are not the same (by reference), we can log a warning such that
"found the topology is built with some StreamsConfig already, which is not the
same as the config passed in the constructor".
> Non-key KTable Joining may result in duplicate schema name in confluence
> schema registry
> ----------------------------------------------------------------------------------------
>
> Key: KAFKA-9925
> URL: https://issues.apache.org/jira/browse/KAFKA-9925
> Project: Kafka
> Issue Type: Bug
> Components: streams
> Affects Versions: 2.4.1
> Reporter: Kin Siu
> Assignee: John Roesler
> Priority: Major
>
> The second half of issue Andy Bryant reported in KAFKA-9390 looks like still
> exist.
> When testing non-key join method without passing in "Named", I noticed that
> there are schema subjects registered in confluent schema registry without
> consumer group Id still,
> e.g.
> {noformat}
> "KTABLE-FK-JOIN-SUBSCRIPTION-REGISTRATION-0000000005-topic-pk-key",
> "KTABLE-FK-JOIN-SUBSCRIPTION-REGISTRATION-0000000005-topic-fk-key",
> "KTABLE-FK-JOIN-SUBSCRIPTION-REGISTRATION-0000000005-topic-vh-value",
> "KTABLE-FK-JOIN-SUBSCRIPTION-REGISTRATION-0000000025-topic-pk-key",
> "KTABLE-FK-JOIN-SUBSCRIPTION-REGISTRATION-0000000025-topic-fk-key",
> "KTABLE-FK-JOIN-SUBSCRIPTION-REGISTRATION-0000000025-topic-vh-value"
> {noformat}
> Code in KTableImpl which constructed above naming :
> https://github.com/apache/kafka/blob/2.4.1/streams/src/main/java/org/apache/kafka/streams/kstream/internals/KTableImpl.java#L959
> When we have multiple topologies using foreignKey join and registered to same
> schema registry, we can have a name clash, and fail to register schema.
> In order to clean up these schema subjects, we will need to know the internal
> naming of a consumer group's topology, which is not straightforward and error
> prone.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
