DUE TO SPAM, SIGN-UP IS DISABLED. Goto Selfserve wiki signup and request an account.
...
The broker may batch writing of records onto the DLQ topic for reasons of efficiency. It is possible in rare situations that more than one DLQ record could be written for a particular undeliverable record. This is because the broker does not guarantee to write the DLQ record onto the DLQ topic atomically with the associated write to the internal share-group state topic.
If the broker fails to write to the DLQ topic, some errors such as stale metadata or a leadership change can obviously be resolved by retrying, and the broker will retry. For other errors, the broker will log an error and the record will progress into the Archived state regardless.
Security considerations
The records are written onto a DLQ topic by a broker which is intrinsically capable of writing to all topics. However, there is a security angle to consider here. If an application writes a record onto a topic T1 for which it has permission, and then causes the record to be treated as undeliverable by a share group with a DLQ topic configured, perhaps by rejecting it explicitly or hitting the maximum number of delivery attempts, the broker will write a DLQ record onto the DLQ topic. The application which wrote the original record onto T1 does not necessarily have permission to write onto the DLQ topic itself. Now let's say that the DLQ topic name configured is the name of a critical business topic, the original application has a convoluted way to write onto this critical topic. This is why the naming of the DLQ topic can be controlled.
A broker configuration errors.deadletterqueue.topic.name.prefix contains the prefix of permitted DLQ topic names. By default, this is "dlq." meaning that DLQ topics must start with this prefix, such as "dlq.T1" . This instantly tells consuming applications that the records they see were indirectly written to this topic. The context headers also indicate that these are potentially DLQ records.
The broker does not by default automatically create DLQ topics, because that again would give a convoluted way of getting the broker to create a topic with a particular name.
...
| Configuration | Description | Values |
|---|---|---|
errors.deadletterqueue.auto.create.topics.enable | Whether to create DLQ topics automatically. Note that automatic creation of the DLQ topics is independent of the auto.create.topics.enable configuration. | Type: boolean, default: false |
errors.deadletterqueue.copy.record.enable | Whether to allow copying the original record onto the dead-letter queue topic for failed record delivery. | Type: boolean, default: true |
errors.deadletterqueue.topic.name.prefix | The prefix of permitted dead-letter queue topic names. If this is set to "", there is no restriction on the names used for dead-letter queue topics. | Type: string, default: "dlq." |
...
| Configuration | Description | Values |
|---|---|---|
errors.deadletterqueue.topic.name | The name of the topic to be used as the dead-letter queue (DLQ) for undeliverable records. The topic name is blank by default, which means that no records are to be records in the DLQthere is no DLQ topic for this group. | Type: string, default: "" |
errors.deadletterqueue.copy.record.enable | Whether to copy the record onto the dead-letter queue topic, or just to write a record containing the context information headers. | Type: boolean, default: false |
...