Status

Current state:  Under discussionVoting

Discussion thread: here

JIRA:

...

On the broker side, receiving a RENEW acknowledgement for a specific batch or offset will cancel the existing acquisition lock timeout task and start a new one with the same timeout value as group.share.record.lock.duration.ms. There is one caveat here. If the application causes a ShareFetch RPC to be sent (poll() call) on which RENEW acknowledgements are piggybacked, it could happen that the renewed acquisition lock again times out before the poll() completes. To get around this, we will not return any new records from the broker side on ShareFetch requests containing RENEW acknowledgements. That way we are guaranteed that the poll()  completes timely and we can return the response of acknowledgements immediately to the application. In order to make it clear when a ShareFetch request is renewing rather than acquiring records, a new value of ShareAcquireMode of RENEW (255) is used. This also implies that we will not honour the maxWaitMs, maxBytes and maxRecords in the ShareFetch request containing ShareAcquireMode value of 255. Hence, we have mentioned in the aforementioned section, that the share consumer should set these fields to 0.

...