Hi Sushant, Thanks for the KIP, overall it looks good. Some comments: AM1: In ProposedChanges we reference "acknowledge(ConsumerRecord, AcknowledgementType)" but the enum class is AcknowledgeType. And same at some other places, also when we reference AcknowledgementType.RENEW.
AM2: There is a reference to UnsupportedAcknowledgementType exception but that neither exists nor the KIP defined. Can we please add the details of the exception in KIP as that will be public facing change. AM3: What happens when the broker fails to Renew the acquisition lock because of an incorrect request i.e. already expired, how does the client send the information back to the application? Do we need to capture those details in the KIP? AM4: In the compatibility section, it's mentioned that "If a broker running the old version of the code receives the *RENEW* ack type in the request, it should consider this an error and return the appropriate error code to the consumer" sorry I couldn't understand this i.e. what are we proposing by this change, we can't modify the already shipped releases? Regards, Apoorv Mittal On Thu, Oct 9, 2025 at 11:49 AM Sushant Mahajan <[email protected]> wrote: > Hi Andrew, > Thanks for the suggestions. I have incorporated all of them and broken down > proposed changes into two sections for better readability. > > For AS2: The proposal is to buffer renew acked records on the share > consumer side and give them to the application appended to subsequent poll > results. This will happen until the record is re-delivered by the broker > after timeout. > > Regards, > Sushant Mahajan > > > On Thu, 9 Oct 2025, 00:58 Andrew Schofield, < > [email protected]> wrote: > > > Hi Sushant, > > Thanks for the KIP. I tried replying previously but messed up so let's > try > > again. > > > > AS1: In the section of Proposed Changes, the KIP states that the > > acknowledge(ConsumerRecord, AcknowledgementType) method > > causes RPCs to be sent. This is incorrect. Only the poll and commit > > methods do this. > > > > AS2: For a situation in which the application is processing for an > > extended period, I would expect it to continue to call > > ShareConsumer.poll(Duration) repeatedly. This method returns > > a set of records to process. In the case where the application > > has renewed its acquisition locks, I would expect the renewed > > records to be returned from the next call to poll(Duration) as a > > way of confirming which records are still in the process of being > > delivered. > > > > AS3: We should specify the error handling where the application > > tries to renew but the broker does not support v2 of the updated > > RPCs. I think ShareConsumer.acknowledge() should throw > > an exception in this case. > > > > Thanks, > > Andrew > > ________________________________________ > > From: Sushant Mahajan <[email protected]> > > Sent: 07 October 2025 11:16 > > To: [email protected] <[email protected]> > > Subject: [DISCUSS] KIP-1222: Acquisition lock timeout renewal in share > > consumer explicit mode > > > > I’d like to start the discussion for KIP-1222: Acquisition lock timeout > > renewal in share consumer explicit mode. > > > > JIRA: https://issues.apache.org/jira/browse/KAFKA-19742 > > KIP Wiki: > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1222%3A+Acquisition+lock+timeout+renewal+in+share+consumer+explicit+mode > > > > Regards, > > Sushant Mahajan > > >
