Hi Luke, Thanks for the review!
LC1: When the consumer starts to read data, then it might need the below offsets: earliest, latest, and last-committed-offset based on the "auto.offset.reset" config. The earliest and latest offsets have special timestamps -2 and -1, those timestamp corresponding offsets are cached in the broker memory and get served immediately. The last-committed-offset is also cached in the GroupMetadata and gets served in the "OFFSET_FETCH" request. Unless the consumer explicitly uses the KafkaConsumer#offsetForTimes API, there won't be any delay in serving the data from the local log. In this KIP, we are trying to address the case in which multiple consumers start at the same time and use the 'offsetForTimes` LIST_OFFSETS API, assuming the remote requests are slow, then it should not block other PRODUCE/FETCH requests. LC2: Sorry for the confusion. We were planning to introduce only the broker config "remote.list.offsets.timeout.ms". If we add the timeout in the ListOffsetsRequest.json, then when old clients talk with the new broker, we don't have a timeout to set on the server. Moved adding the timeout to the ListOffsetsRequest to the rejected alternatives section. -- Kamal
