Seems I am late to the party, and the vote already passed.
Two comments from my side:
(1) KAFKA-13152 is backed by KIP-770 which was accepted. We just did not
complete the implementation yet. Thus, I would personally prefer to
follow KIP-770 approach for this KIP, too, and make the config byte
based to begin with. This would avoid to add new config we would
deprecate again anyway...
Also, nobody is working to complete KIP-770 atm, and I would really like
to complete it. Maybe Muralidhar would be interested to pick it up? This
way, we might be able to move both config to be byte based at the same time.
(2) About the pause/resume quest: for the existing config (count base,
and also future byte based config via KIP-770), we don't have a lower
bound when to resume, and I don't think we need one. In the end, we want
to bound the buffer what we achieve. I would only make it more complex
is there is indeed a issue we need to solve, but no user ever reported a
problem, so I would keep it simple.
-Matthias
On 5/25/26 4:43 AM, Muralidhar Basani via dev wrote:
Hi Chia, that’s a valid point.
I shall add to kip that based on the benchmarks, we decide to add another
lower bound or not.
It could be a follow-up.
Thanks,
Murali
On Sat, 23 May 2026 at 08:22, Chia-Ping Tsai <[email protected]> wrote:
Should we introduce a lower bound to avoid bouncing between pause and
resume? For example, a paused partition should only be resumed once the
buffered records drop below 50% of the max capacity
On 2026/04/24 17:11:08 Muralidhar Basani via dev wrote:
Hi all,
I would like to start a discussion on KIP-1325, which introduces a new
streams config to handle message fetching in the restore path.
KIP :
https://cwiki.apache.org/confluence/display/KAFKA/KIP-1325%3A+Add+restore.buffered.records.per.partition+to+cap+Kafka+Streams+state-restore+memory
Thanks,
Murali
