---
title: "Renew a Kafka share group acquisition lock (KIP-1222)"
description: "A slow handler sends RENEW before its 1000 ms lock expires and keeps the record, while a Kafka share group without renew loses the lock and gets a duplicate."
url: https://monedula.dev/kafka-simulator/scenarios/renew-acquisition-lock/
---

# Renew a Kafka share group acquisition lock (KIP-1222)

Scenario 11.0.8 · RENEW: extending an acquisition lock. Share groups · Advanced · about 3 min · Apache Kafka 4.3.

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 it: https://monedula.dev/kafka-simulator/playground/?scenario=11.0.8

## What 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

1. **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](https://monedula.dev/kafka-simulator/playground/?scenario=11.0.8&t=0)
2. **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](https://monedula.dev/kafka-simulator/playground/?scenario=11.0.8&t=1)
3. **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](https://monedula.dev/kafka-simulator/playground/?scenario=11.0.8&t=2)
4. **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](https://monedula.dev/kafka-simulator/playground/?scenario=11.0.8&t=3)
5. **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](https://monedula.dev/kafka-simulator/playground/?scenario=11.0.8&t=4)

## 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.renew.acknowledge.enable`](https://kafka.apache.org/43/configuration/group-configs/#groupconfigs_share.renew.acknowledge.enable): 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.

## Further reading

- [KIP-1222 on the Apache Kafka wiki](https://cwiki.apache.org/confluence/display/KAFKA/KIP-1222%3A+Acquisition+lock+timeout+renewal+in+share+consumer+explicit+mode)