Hi Jorge, Thanks for the review! Added your suggestions to the KIP. PTAL.
The `fetch.max.wait.ms` config will be also applicable for topics enabled with remote storage. Updated the description to: ``` The maximum amount of time the server will block before answering the fetch request when it is reading near to the tail of the partition (high-watermark) and there isn't sufficient data to immediately satisfy the requirement given by fetch.min.bytes. ``` -- Kamal On Thu, Feb 1, 2024 at 12:12 AM Jorge Esteban Quilcate Otoya < quilcate.jo...@gmail.com> wrote: > Hi Kamal, > > Thanks for this KIP! It should help to solve one of the main issues with > tiered storage at the moment that is dealing with individual consumer > configurations to avoid flooding logs with interrupted exceptions. > > One of the topics discussed in [1][2] was on the semantics of ` > fetch.max.wait.ms` and how it's affected by remote storage. Should we > consider within this KIP the update of `fetch.max.wail.ms` docs to clarify > it only applies to local storage? > > Otherwise, LGTM -- looking forward to see this KIP adopted. > > [1] https://issues.apache.org/jira/browse/KAFKA-15776 > [2] https://github.com/apache/kafka/pull/14778#issuecomment-1820588080 > > On Tue, 30 Jan 2024 at 01:01, Kamal Chandraprakash < > kamal.chandraprak...@gmail.com> wrote: > > > Hi all, > > > > I have opened a KIP-1018 > > < > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1018%3A+Introduce+max+remote+fetch+timeout+config+for+DelayedRemoteFetch+requests > > > > > to introduce dynamic max-remote-fetch-timeout broker config to give more > > control to the operator. > > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1018%3A+Introduce+max+remote+fetch+timeout+config+for+DelayedRemoteFetch+requests > > > > Let me know if you have any feedback or suggestions. > > > > -- > > Kamal > > >
