jolshan commented on code in PR #15968:
URL: https://github.com/apache/kafka/pull/15968#discussion_r1621535872
##########
clients/src/main/java/org/apache/kafka/clients/producer/internals/Sender.java:
##########
@@ -610,7 +611,9 @@ private void handleProduceResponse(ClientResponse response,
Map<TopicPartition,
// This will be set by completeBatch.
Map<TopicPartition, Metadata.LeaderIdAndEpoch>
partitionsWithUpdatedLeaderInfo = new HashMap<>();
produceResponse.data().responses().forEach(r ->
r.partitionResponses().forEach(p -> {
- TopicPartition tp = new TopicPartition(r.name(),
p.index());
+ // Version 12 drop topic name and add support to topic id.
However, metadata can be used to map topic id to topic name.
+ String topicName = (r.name() == null ||
r.name().isEmpty()) ? metadata.topicNames().get(r.topicId()) : r.name();
Review Comment:
Yes. For the fetch request for example, there is code to make sure that all
topics have IDs before we can send the fetch request. This is a bit less of an
issue now, but if we have a cluster that is running on a MV < 2.8, topics will
not have IDs. So when we decide which version of produce we want to send, we
want to be aware of this.
Not only that, but even if the broker supports topic IDs on all topics, we
also may have a case where we need to do a rolling upgrade to get the code that
supports handling the latest API version. This may be less complicated for
Produce since it is a client only API and doesn't rely on MV/IBP, so the
apiVersions exchange between the client and the broker may be enough to ensure
api compatibility.
We just want to confirm these upgrade paths are compatible since produce is
the hot path and we don't want any (or at least not extended) downtime in the
middle of an upgrade.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
