[
https://issues.apache.org/jira/browse/KAFKA-19923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18043209#comment-18043209
]
Matthias J. Sax commented on KAFKA-19923:
-----------------------------------------
{quote}To be honest, since I don't have much experience contributing to Kafka
yet, I wasn't entirely sure about the strict scope of Breaking Changes in this
project.
I really appreciate you clarifying that moving an existing runtime failure to a
build-time check is considered a fix/improvement rather than a breaking change.
That makes perfect sense.
{quote}
We do not get a build-time (ie, compile time) exception. We still get a runtime
exception, we just get it much earlier, ie, when calling `build()`, instead of
after calling `start()`. It's IMHO still not a breaking change, as the end
result is the same. You cannot run the program. (But these question are often
not easy to answer, so it's good we are discussion it.)
Great call out about lambda and generic serdes. This make the situation more
nuanced, and could actually be a problem in the category of undesired backward
incompatibility. Might be good to the input from others on this question. \cc
[~lucasbru] [~billdback] [~lianetm]
Need to think about this on my own a little bit more. I guess it really depends
if we favor "safety" over "ease of use". _thinking_
> Kafka Streams throws ClassCastException with different Consumed instances.
> --------------------------------------------------------------------------
>
> Key: KAFKA-19923
> URL: https://issues.apache.org/jira/browse/KAFKA-19923
> Project: Kafka
> Issue Type: Bug
> Components: streams
> Reporter: sanghyeok An
> Assignee: sanghyeok An
> Priority: Minor
>
> Kafka Streams throws a ClassCastException when using different Consumed
> instances for the same topic.
> For example:
> {code:java}
> builder.stream("A", Consumed.with(Serdes.String(), Serdes.String()))
> .peek((k, v) -> System.out.println(k));
> builder.stream("A", Consumed.with(Serdes.ByteArray(), Serdes.ByteArray()))
> .peek((k, v) -> System.out.println(k));
> {code}
>
> Since both use the same topic name and the same ConsumedInternal
> configuration for auto offset reset, these two StreamSourceNodes are merged
> during topology building.
>
> As a result, the Topology is built successfully.
>
> However, when the StreamThread starts, the consumer begins to receive records
> from the broker, and the records flow through the pipeline, a
> ClassCastException is thrown at runtime.
>
> In my opinion, we have two options:
> # Document this behavior.
> # When merging source nodes, the builder should consider the full
> ConsumedInternal configuration (for example, key/value SerDes and timestamp
> extractor), instead of only the auto offset reset policy.
>
> I think option 1 is also acceptable, because Kafka Streams will fail fast
> with a ClassCastException before the consumer commits any offsets.
>
> Option 2 would require more substantial changes in Kafka Streams, because
> TimestampExtractor and key/value SerDes do not expose a straightforward way
> to check semantic equivalence.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
