Thanks both for looking into this.
Jose,
1/2 & 4(changes for PRODUCE) & 5 makes sense, will follow
3. If I understood this correctly, certain replicas "aren't" brokers, what
are they then?
Also how about replacing "Replica" with "Leader", this is more readable on
the client. so, how about this?
{ "name": "LeaderEndpoints", "type": "[]Leader", "versions": "15+",
"taggedVersions": "15+", "tag": 3,
"about": "Endpoints for all current leaders enumerated in
PartitionData.", "fields": [
{ "name": "NodeId", "type": "int32", "versions": "15+",
"mapKey": true, "entityType": "brokerId", "about": "The ID of the
associated leader"},
{ "name": "Host", "type": "string", "versions": "15+",
"about": "The leader's hostname." },
{ "name": "Port", "type": "int32", "versions": "15+",
"about": "The leader's port." },
{ "name": "Rack", "type": "string", "versions": "15+", "ignorable":
true, "default": "null",
"about": "The rack of the leader, or null if it has not been
assigned to a rack." }
]}
Andrew
6. I wonder if non-Kafka clients might benefit from not bumping the
version. If versions are bumped, say for FetchResponse to 16, I believe
that client would have to support all versions until 16 to fully utilise
this feature. Whereas, if not bumped, they can simply support until version
12( will change to version:12 for tagged fields ), and non-AK clients can
then implement this feature. What do you think? I am inclined to not bump.
On Thu, Jul 13, 2023 at 5:21 PM Andrew Schofield <
andrew_schofield_j...@outlook.com> wrote:
> Hi José,
> Thanks. Sounds good.
>
> Andrew
>
> > On 13 Jul 2023, at 16:45, José Armando García Sancio
> <jsan...@confluent.io.INVALID> wrote:
> >
> > Hi Andrew,
> >
> > On Thu, Jul 13, 2023 at 8:35 AM Andrew Schofield
> > <andrew_schofield_j...@outlook.com> wrote:
> >> I have a question about José’s comment (2). I can see that it’s
> possible for multiple
> >> partitions to change leadership to the same broker/node and it’s
> wasteful to repeat
> >> all of the connection information for each topic-partition. But, I
> think it’s important to
> >> know which partitions are now lead by which node. That information at
> least needs to be
> >> per-partition I think. I may have misunderstood, but it sounded like
> your comment
> >> suggestion lost that relationship.
> >
> > Each partition in both the FETCH response and the PRODUCE response
> > will have the CurrentLeader, the tuple leader id and leader epoch.
> > Clients can use this information to update their partition to leader
> > id and leader epoch mapping.
> >
> > They can also use the NodeEndpoints to update their mapping from
> > replica id to the tuple host, port and rack so that they can connect
> > to the correct node for future FETCH requests and PRODUCE requests.
> >
> > Thanks,
> > --
> > -José
>
>
--
Regards,
Mayank Shekhar Narula
