Hi Mayank, If we bump the version, the broker can tell whether it’s worth providing the leader endpoint information to the client when the leader has changed. That’s my reasoning.
Thanks, Andrew > On 13 Jul 2023, at 18:02, Mayank Shekhar Narula <mayanks.nar...@gmail.com> > wrote: > > 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