Hey Jorge I understand the pain point which is driving this KIP. An operator should be able to proactively mitigate an impending OOM due to large number of producers.
I would like to hear your thoughts on alternative ways to solve this problem. As an example, we could potentially add an operator tool (via command line / Admin API) to forcefully expire producer IDs beyond a certain time. This API offers multiple advantages over the proposed solution, such as ability to selectively evict a producer and limit access to admin operators (via API ACLs). Could you please evaluate the API approach (and other alternatives) to solve this issue? — Divij Vaidya On Thu 16. May 2024 at 22:15, Jorge Esteban Quilcate Otoya < quilcate.jo...@gmail.com> wrote: > Thanks Justine. I have updated the KIP with the configuration details. > > On Thu, 16 May 2024 at 21:14, Justine Olshan <jols...@confluent.io.invalid > > > wrote: > > > Hey Jorge, > > > > Thanks for the KIP. I didn't realize until I read the details that this > > configuration is currently not public at all. I think it is still ok that > > we are exposing the value though. Can we just include some information > > about the current default, the documentation etc that is already defined > as > > this will now become part of the public documentation? > > > > Thanks, > > Justine > > > > On Thu, May 16, 2024 at 10:23 AM Jorge Esteban Quilcate Otoya < > > quilcate.jo...@gmail.com> wrote: > > > > > Hi dev team, > > > > > > I'd like to start a discussion thread for KIP-1046: > > > > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1046%3A+Expose+producer.id.expiration.check.interval.ms+as+dynamic+broker+configuration > > > > > > This KIP aims to align how tuning configurations for Producer ID > > expiration > > > checks are exposed. > > > > > > Looking forward to your feedback. > > > > > > Cheers, > > > Jorge. > > > > > >
