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
