I have updated the KIP and intend to open voting tomorrow if there are no additional comments.
Thanks, Andrew On 2026/01/13 10:09:44 Andrew Schofield wrote: > Hi Chia-Ping, > That seems like a very sensible approach. I will update the KIP accordingly. > > Thanks, > Andrew > > On 2026/01/09 19:04:47 Chia-Ping Tsai wrote: > > hi Andrew, > > > > I'd like to propose a hybird approach for handling these bounds, treating > > the broker-level configs as a "safety cap" rather than just a static > > validator. > > > > here is the logic: > > > > 1. on group config update (strict validation): we validate it against the > > current broker-level cap. If it exceed the cap, we reject the request. This > > prevents new invalid configs from entering the system > > > > 2. on broker config update (non-blocking): we don't validate against > > existing groups. This ensures that admins can tighten limits uring an > > emergency > > > > 3. at runtime (effective value enforcement): the broker uses the logic > > `min(groupConfig, brokerCap). Even if a legacy group config is higher than > > the new broker cap (due to step 2), the runtime behavious will be clamped > > to the broker cap > > > > WDYT? > > > > Best, > > Chia-Ping > > > > On 2026/01/07 17:24:21 Andrew Schofield wrote: > > > Hi Chia-Ping, > > > Thanks for your comments. > > > > > > chia_00: The group-level configs are all dynamic. This means that when > > > the limits > > > are reduced, they may already be exceeded by active usage. Over time, as > > > records > > > are delivered and locks are released, the system will settle within the > > > new limits. > > > > > > chia_01: This is an interesting question and there is some work off the > > > back of it. > > > > > > For the interval and timeout configs, the broker will fail to start when > > > the group-level > > > config lies outside the min/max specified by the static broker configs. > > > However, the > > > logging when the broker fails to start is unhelpful because it omits the > > > group ID of > > > the offending group. This behaviour is common for consumer groups and > > > share groups. > > > I haven't tried streams groups, but I expect they're the same. This > > > should be improved > > > in terms of logging at the very least so it's clear what needs to be done > > > to get the broker > > > started. > > > > > > For share.record.lock.duration.ms, no such validation occurs as the > > > broker starts. This > > > is an omission. We should have the same behaviour for all of the min/max > > > bounds > > > I think. My view is failing to start the broker is safest for now. > > > > > > For the new configs in the KIP, the broker should fail to start if the > > > group-level config > > > is outside the bounds of the min/max static broker configs. > > > > > > wdyt? I'll make a KIP update when I think we have consensus. > > > > > > Thanks, > > > Andrew > > > > > > On 2026/01/05 13:56:16 Chia-Ping Tsai wrote: > > > > hi Andrew > > > > > > > > Thanks for the KIP. I have a few questions regrading the configuration > > > > behaviour: > > > > > > > > chia_00: Dynamic Update Behavior > > > > Are these new group-level configuration dynamic? Specifically, if we > > > > alter share.delivery.count.limit or share.partition.max.record.locks at > > > > runtime, will the changes take effect immediately for active share > > > > group? > > > > > > > > chia_01: Configuration Validation on Broker Restart > > > > How does the broker handle existing group configuration that fall out > > > > of bounds after a broker restart? For example, suppose a group has > > > > share.partition.max.record.locks set to 100 (which is valid at the > > > > time). If the broker is later restarted with a stricter limit of > > > > group.share.max.partition.max.record.locks = 50, how will the group > > > > loaded handle this conflict? > > > > > > > > Best, > > > > Chia-Ping > > > > > > > > On 2025/11/24 21:15:48 Andrew Schofield wrote: > > > > > Hi, > > > > > I’d like to start the discussion on a small KIP which adds some > > > > > configurations for share groups which were previously only available > > > > > as broker configurations. > > > > > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1240%3A+Additional+group+configurations+for+share+groups > > > > > > > > > > Thanks, > > > > > Andrew > > > > > > > > > > > > > > >
