What causes CommitFailedException?

Processing a batch from poll() took longer than max.poll.interval.ms (default 300000ms / 5min), so the broker considered the consumer dead and rebalanced the group away from it The consumer was removed from the group (session timeout, network partition, or a manual unsubscribe) before commitSync() could complete Committing offsets after the partitions were already revoked and reassigned to another member

How do I fix CommitFailedException?

Reduce max.poll.records so each poll() batch finishes well within max.poll.interval.ms, or increase max.poll.interval.ms if per-record work is genuinely long Move slow/blocking work off the poll loop (e.g. hand records to a worker pool) and pause()/resume() partitions instead of blocking the consumer thread Use the ConsumerRebalanceListener.onPartitionsRevoked callback to commit before partitions are taken away, and treat CommitFailedException on async paths as a signal to re-poll rather than crash

Is CommitFailedException retriable?

No — CommitFailedException is not retriable. Retrying the same call will not help; the underlying cause must be fixed first.

Kafka Exception `CommitFailedException`

org.apache.kafka.clients.consumer.CommitFailedException

Non-retriable Consumer

This exception is raised when an offset commit with commitSync() fails with an unrecoverable error. This exception is generated on the client side, typically when a group rebalance completes before the commit could be successfully applied. In this case, the commit cannot generally be retried because some of the partitions may have already been assigned to another member in the group.

Common Causes

Processing a batch from poll() took longer than max.poll.interval.ms (default 300000ms / 5min), so the broker considered the consumer dead and rebalanced the group away from it
The consumer was removed from the group (session timeout, network partition, or a manual unsubscribe) before commitSync() could complete
Committing offsets after the partitions were already revoked and reassigned to another member

Solutions

Reduce max.poll.records so each poll() batch finishes well within max.poll.interval.ms, or increase max.poll.interval.ms if per-record work is genuinely long
Move slow/blocking work off the poll loop (e.g. hand records to a worker pool) and pause()/resume() partitions instead of blocking the consumer thread
Use the ConsumerRebalanceListener.onPartitionsRevoked callback to commit before partitions are taken away, and treat CommitFailedException on async paths as a signal to re-poll rather than crash

Example Stack Trace

org.apache.kafka.clients.consumer.CommitFailedException: Commit cannot be completed since the group has already rebalanced and assigned the partitions to another member. This means that the time between subsequent calls to poll() was longer than the configured max.poll.interval.ms, which typically implies that the poll loop is spending too much time message processing.
	at org.apache.kafka.clients.consumer.internals.ConsumerCoordinator.sendOffsetCommitRequest(ConsumerCoordinator.java:1190)
	at org.apache.kafka.clients.consumer.internals.ConsumerCoordinator.commitOffsetsSync(ConsumerCoordinator.java:1029)
	at org.apache.kafka.clients.consumer.KafkaConsumer.commitSync(KafkaConsumer.java:1530)

Diagnostic Commands

# Inspect the group: state, members, and per-partition lag
kafka-consumer-groups.sh --bootstrap-server localhost:9092 --group <group> --describe --members --verbose

Hitting CommitFailedException in production? Conduktor Console gives you real-time visibility into clients, consumer groups, and broker health. Browse every Kafka exception or protocol error code.

Kafka Exception CommitFailedException

Common Causes

Solutions

Example Stack Trace

Diagnostic Commands

Related

Kafka Exception `CommitFailedException`