Scenario 11.0.8 · RENEW: extending an acquisition lock
Renew a Kafka share group acquisition lock (KIP-1222)
A long-running handler RENEWs its lock before it expires (share.renew.acknowledge.enable) - the record stays acquired, never redelivered, while a control group without renew loses the lock and gets a duplicate.
Run this scenario in the playgroundCluster ready · idle. t+0.000s
One record and two explicit-ack share groups identical except for share.renew.acknowledge.enable: 'renew' (on) vs 'norenew' (off). Both will acquire offset 0 under a 1000ms lock. Press ▶.
Open at this step: step 1, Cluster ready · idleBoth groups acquire offset 0. t+0.700s
First poll (600ms): both members acquire offset 0 (deliveryCount 1), lock held until 1600ms. A slow handler is now processing the record in each group.
Open at this step: step 2, Both groups acquire offset 0Renew extends the lock. t+1.500s
At 1400ms - before the 1600ms deadline - the 'renew' group sent share_ack ackType=renew, pushing its lockExpiresAt from 1600 to 2400ms. 'norenew' did nothing; its lock still expires at 1600. Both records are still acquired at deliveryCount 1; only the renew group's deadline moved.
Open at this step: step 3, Renew extends the lockLock expiry: renew held, control released. t+1.700s
At 1600ms the original deadline passes. 'norenew' never renewed → its lock expired → offset 0 released to 'available'. 'renew' has already pushed its deadline to 2400, so the stale 1600 timer is a no-op and the record stays acquired. That is the point of RENEW: a long-running handler keeps its lock alive instead of losing the record.
Open at this step: step 4, Lock expiry: renew held, control releasedControl redelivered; renew never duplicated. t+1.900s
The 1800ms poll re-acquires 'norenew' offset 0 → deliveryCount 2: a DUPLICATE delivery. 'renew' is still acquired at deliveryCount 1 - it was never redelivered because the handler renewed its lock instead of letting it lapse.
Open at this step: step 5, Control redelivered; renew never duplicatedWhat you start with
KIP-1222 adds a RENEW acknowledgement so a consumer that needs more time can extend its acquisition lock instead of losing the record. Two explicit-ack groups acquire the same record under a 1000ms lock; the renew group sends a renew before the deadline (pushing expiry out to 2400ms), while the control group (renew disabled) lets the lock expire and gets the record redelivered.
Step by step
- Cluster ready · idle t+0.000s One record and two explicit-ack share groups identical except for share.renew.acknowledge.enable: 'renew' (on) vs 'norenew' (off). Both will acquire offset 0 under a 1000ms lock. Press ▶. Open at this step: step 1, Cluster ready · idle
- Both groups acquire offset 0 t+0.700s First poll (600ms): both members acquire offset 0 (deliveryCount 1), lock held until 1600ms. A slow handler is now processing the record in each group. Open at this step: step 2, Both groups acquire offset 0
- Renew extends the lock t+1.500s At 1400ms - before the 1600ms deadline - the 'renew' group sent share_ack ackType=renew, pushing its lockExpiresAt from 1600 to 2400ms. 'norenew' did nothing; its lock still expires at 1600. Both records are still acquired at deliveryCount 1; only the renew group's deadline moved. Open at this step: step 3, Renew extends the lock
- Lock expiry: renew held, control released t+1.700s At 1600ms the original deadline passes. 'norenew' never renewed → its lock expired → offset 0 released to 'available'. 'renew' has already pushed its deadline to 2400, so the stale 1600 timer is a no-op and the record stays acquired. That is the point of RENEW: a long-running handler keeps its lock alive instead of losing the record. Open at this step: step 4, Lock expiry: renew held, control released
- Control redelivered; renew never duplicated t+1.900s The 1800ms poll re-acquires 'norenew' offset 0 → deliveryCount 2: a DUPLICATE delivery. 'renew' is still acquired at deliveryCount 1 - it was never redelivered because the handler renewed its lock instead of letting it lapse. Open at this step: step 5, Control redelivered; renew never duplicated
The takeaway
Lock renewal lets a slow-but-healthy handler keep a record without triggering redelivery - extend the lock for long processing; letting it expire instead causes duplicate delivery.
Configs in this scenario
-
share.Whether a share-group member may send a RENEW acknowledgement to extend its acquisition lock on an in-flight record instead of releasing or rejecting it - useful when processing legitimately takes longer than lock.duration.ms, so the record is not redelivered to another member while it is still being worked on.renew. acknowledge. enable
Embed this scenario
Paste this into a blog post, a course page or your team's docs. The scenario plays inside your page, and the link under it points readers to this walkthrough.
<iframe src="https://monedula.dev/kafka-simulator/embed/?scenario=11.0.8" title="Kafka Simulator: RENEW: extending an acquisition lock" width="100%" height="520" style="border:1px solid #d0d0d0;border-radius:8px" loading="lazy"></iframe>
<p><a href="https://monedula.dev/kafka-simulator/scenarios/renew-acquisition-lock/">Renew a Kafka share group acquisition lock (KIP-1222)</a></p>Further reading
KIP-1222 on the Apache Kafka wiki
More in Share groups
- Kafka share groups: queue semantics with KIP-932
- More Kafka consumers than partitions with share groups
- Kafka share group acquisition lock timeout and redelivery
- Kafka share consumer acknowledge: accept, release, reject
- Kafka share group poison pill: delivery limit and archiving
- Kafka share.acknowledgement.mode: implicit vs explicit
- Kafka share.acquire.mode: batch_optimized vs record_limit
- Kafka share group lag: SPSO, SPEO and the acked prefix