SECURITY WARNING: Never run commands you don't understand. Always review code before execution. Use at your own risk.
MessageQueue New Added 8 September 2026

Kafka: RecordTooLargeException

A message exceeded a size limit. Three separate limits must agree: the producer's max.request.size, the broker or topic's max.message.bytes, and the consumer's fetch size, so raising one alone moves the failure rather than fixing it.

Quick fix

Read the commands before running them. Anything that restarts a service, deletes data or changes permissions should be tried on a non-production system first.

Quick fix
# Broker or topic side
kafka-configs.sh --bootstrap-server broker:9092 --entity-type topics \
  --entity-name events --describe
kafka-configs.sh --bootstrap-server broker:9092 --entity-type topics \
  --entity-name events --alter --add-config max.message.bytes=5242880

# Producer
max.request.size=5242880
compression.type=zstd        # often enough on its own

# Consumer
max.partition.fetch.bytes=5242880

# Better pattern for large payloads: put the blob in object storage
# and publish a reference to it.

How to diagnose MessageQueue errors

Queue errors are usually about the balance between producers and consumers. Growing lag means consumers cannot keep up. Endless rebalancing usually means consumers are being evicted for exceeding a poll or heartbeat interval, not that the cluster is unhealthy. A poison message, one that always fails processing, will block an ordered partition forever unless there is a dead-letter path, which is why a DLQ is not optional in production.

If the quick fix above does not resolve it, work through these steps. They apply to this whole class of error, not just to this one message, which is usually what saves the time.

  1. Measure lag over time, not once: kafka-consumer-groups --describe --group <g>. The trend distinguishes a throughput problem from a stuck consumer.
  2. For repeated rebalancing, compare processing time per batch against max.poll.interval.ms. Slow processing looks exactly like a dead consumer to the coordinator.
  3. Always configure a dead-letter queue with a bounded retry count. Without one, a single malformed message stops the partition indefinitely.
  4. Check message size against the broker limit before assuming a network failure: SQS caps at 256 KB, Kafka at message.max.bytes.
  5. Verify consumer ACLs and topic authorisation separately from connectivity; an authorisation failure often surfaces as a metadata error.

Tools worth reaching for

  • kafka-consumer-groups
  • rabbitmqctl list_queues
  • aws sqs get-queue-attributes
  • kafkacat / kcat
  • flower (Celery)

Authoritative references

Primary documentation for this error, worth reading before applying any fix in production.

kafka.apache.org

Related MessageQueue errors

See all 14 MessageQueue errors →

Browse other categories

Something missing or wrong?

This entry is maintained by hand. If the fix is out of date, incomplete, or you have a better one, email a correction and it will be reviewed.