Hello Matthias, Thanks for your feedback, I have updated the table.
Best Regards, Jiunn-Yang > Matthias J. Sax <[email protected]> 於 2026年3月4日 清晨7:07 寫道： > > Thanks for the KIP. Overall LGTM. > > Can we add a column to the Behavior Matrix for "Classic/static" case? > > It might also be useful, to show "existing" vs "new" behavior to make it > easier to compare? Maybe change the rows to: > > - close() [current] -> same as close(REMAIN) > - close() [new] -> same as close(DEFAULT) > - close(REMAIN) [current] > - close(REMAIN) [new] > - close(LEAVE) [current] > - close(LEAVE) [new] > > And we could use cell background colors to highlight the change for "streams" > protocol and REMAIN case? > > > -Matthias > > > > On 3/2/26 6:12 AM, 黃竣陽 wrote: >> Hello Sanghyeok An, >> Thanks for the feedback, >> The consumer already has corresponding close semantics that differentiate >> behavior >> based on membership, and in that context I agree that having static members >> remain in the group >> by default is reasonable and consistent with the goal of static membership. >> Based on this, I plan to make the behavior explicit in the KIP: under the >> Streams Protocol, >> CloseOptions.DEFAULT will resolve to remain in group for static members, >> while keeping >> the existing behavior for dynamic members. >> Best Regards, >> Jiunn-Yang >>> Sanghyeok An <[email protected]> 於 2026年2月27日 晚上10:57 寫道： >>> >>> Hi Jiunn-Yang, >>> Thanks for the this KIP. >>> >>> I have a small question. >>> >>> ash01 : >>> Would it be worth considering mapping CloseOptions.DEFAULT differently not >>> only based on the protocol, but also on whether the member is static? >>> >>> I recently worked on a server-side implementation of static membership for >>> KIP-1071. >>> Once static members are supported under the Streams Protocol, DEFAULT close >>> semantics may reasonably differ between dynamic and static members. >>> >>> For dynamic members, I agree with the KIP rationale that remaining in the >>> group provides no real benefit, so having DEFAULT map to a leave behavior >>> under the Streams Protocol makes sense. >>> However, for static members, making leave the default would weaken the >>> primary benefit of static membership, minimizing rebalances on restart. >>> >>> Would it make sense to resolve DEFAULT under the Streams Protocol as >>> follows? >>> - dynamic member: DEFAULT maps to consumer CloseOptions.DEFAULT (leave) >>> - static member: DEFAULT maps to consumer CloseOptions.REMAIN_IN_GROUP >>> (remain) >>> >>> This would keep the no-arg KafkaStreams.close() as a safer default in both >>> cases, while still reserving REMAIN_IN_GROUP as an explicit user intent. >>> Curious what you think, and whether this should be in scope for this KIP or >>> tracked as a follow-up. >>> >>> Thanks for reading this! >>> >>> Best Regards >>> Sanghyeok An >>> >>> -----Original Message----- >>> From: "Lucas Brutschy via dev"<[email protected]> >>> To: <[email protected]>; >>> Cc: "Lucas Brutschy"<[email protected]>; >>> Sent: 2026-02-24 (화) 21:26:47 (GMT+09:00) >>> Subject: Re: [DISCUSS] KIP-1284 Introduce CloseOptions.DEFAULT for Kafka >>> Streams >>> >>> Hi Jiunn-Yang, >>> >>> Thanks for the update; it looks good to me. >>> >>> Cheers, >>> Lucas >>> >>> On Tue, Feb 24, 2026 at 12:33 PM 黃竣陽 <[email protected]> wrote: >>>> >>>> Hi Lucas, >>>> >>>> Thanks for your feedback, I have updated the KIP. >>>> >>>> Best Regards, >>>> Jiunn-Yang >>>> >>>>> Lucas Brutschy via dev <[email protected]> 於 2026年2月23日 晚上11:00 寫道： >>>>> >>>>> Hi Jiunn-Yang, >>>>> >>>>> Thanks for the KIP! I think it's correct and pretty much reflects what >>>>> was written in the ticket. >>>>> >>>>> One thing to point out explicitly is that there _is_ a behavioral >>>>> change. People using REMAIN_IN_GROUP explicitly now with streams >>>>> groups, the member left before theis KIP and will remain with this >>>>> KIP. However, I think this is rarely used because it explicitly states >>>>> the (old) default. Specifically with KIP-1071, I don't think many >>>>> people will use it. I consider the behavioral change here more a bug >>>>> fix that we are implementing as part of this KIP, but I would still >>>>> point it out in the KIP. >>>>> >>>>> Thanks, >>>>> Lucas >>>>> >>>>> >>>>> >>>>> On Mon, Feb 23, 2026 at 2:32 PM 黃竣陽 <[email protected]> wrote: >>>>>> >>>>>> Hello everyone, >>>>>> >>>>>> I would like to start a discussion on KIP-1284 Introduce >>>>>> CloseOptions.DEFAULT for Kafka Streams >>>>>> <https://cwiki.apache.org/confluence/x/1ow8G> >>>>>> >>>>>> This proposal aims to introduce CloseOptions.DEFAULT to resolve semantic >>>>>> inconsistency >>>>>> in KafkaStreams shutdown behavior across protocols. >>>>>> >>>>>> Best regards, >>>>>> Jiunn-Yang >>>> >
