Hi Sushant, Thanks for the updates. AS5: You mention that a broker which does not support v2 of ShareFetch/Acknowledge would not be able to support RENEW. You then mention that the exception COULD be UnsupportedVersionException. It would be good if the KIP specified the exception to be used explicitly.
In practice, this will be very unlikely to occur, assuming that this KIP is delivered in Apache Kafka 4.2 because earlier versions are not production-ready. As a result, I would not define an exception specifically for this case and UnsupportedVersionException with an appropriate message should suffice. AS6: In the section on broker-side changes, you say that a ShareFetch which includes RENEW acknowledgements will not return any records. Also, it will return as soon as the acknowledgements have been processed, regardless of the value of MaxWaitMs in the request. We want to return the acknowledgement error code promptly without running down the renewed acquisition lock time. Thanks, Andrew > On 13 Oct 2025, at 09:51, Andrew Schofield <[email protected]> wrote: > > Hi Sushant, > Thanks for the updates. > > AS4: Adding UnsupportedAcknowledgeTypeException is OK, but > I don’t think it’s correct to inherit from InvalidConfigurationException. > Because that’s an ApiException, it’s related to a specific error code > in the Kafka protocol. I don’t think we want to introduce a new > error code in the Kafka protocol, which would imply that the broker > is able to return it. > > Two options given that. First, you could instead extend KafkaException > for your new exception class. Second, you could just use the > standard Java IllegalArgumentException if the acknowledge type is > not supported. > > > Thanks, > Andrew > >> On 9 Oct 2025, at 11:48, 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 >>> >
