Page History

...

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 (indicated by the IsRenewAck field). 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 A true value of IsRenewAck makes it clear when a that a ShareFetch request is renewing rather than acquiring records, . If IsRenewAck will be is set to true. This also implies that we will not honour the , MaxWaitMs, MinBytes, MaxBytes and MaxRecords in the ShareFetch request containing IsRenewAck value of true. Hence, we have mentioned in the aforementioned section, that the share consumer should set these fields must be set to 0. By Also, by looking at the value of the top level field IsRenewAck, the broker could process the request a bit more optimally.

...