Page History

...

A new configuration will be added: errors.deadletterqueuedead.letter.queue.topic.name. When set, this configuration indicates the default exception handler implementation to build a Dead letter queue record during the error handling.

...

1. Add a new getter and setter to configure dead letter queue records in the DeserializationExceptionHandler, ProductionExceptionHandler and ProcessExceptionHandler.
2. Add a new attribute public static final String ERRORS_DEAD_LETTER_DEADLETTERQUEUEQUEUE_TOPIC_NAME_CONFIG = "errors.dead.letter.deadletterqueuequeue.topic.name".
3. Change the existing exception handler to produce a DeadLetterQueue record if the parameter errors.dead.letter.deadletterqueuequeue.topic.name is set.
4. If the DeadLetterQueue record can not be sent to Apache Kafka, the exception would be sent to the Kafka Streams uncaughtExceptionHandler.

...

The DLQ topic name is set through the configuration ERRORS_DEAD_LETTER_DEADLETTERQUEUEQUEUE_TOPIC_NAME_CONFIG = " errors.dead.letter.deadletterqueuequeue.topic.name". Users can override the default behavior by implementing custom exception handlers to implement a different DLQ topic strategy if required.

...

If the user implements a custom exception handler, it is up to the custom handler to build DLQ records to send, in this case, the the errors.dead.letter.deadletterqueuequeue.topic.name configuration has no impact.

...

• Managing DeadLetterQueue directly in the DSL by extending the KStreams interface.
• Providing no default implementation to build the Dead letter queue record and delegating this task to the user.
• Only providing exception and metadata information in the default DLQ implementation.
• Adding a new interface, that could be overloaded by the user, to build the DLQ records.
• Adding dead letter queue records to the enum: problematic because the collection would be shared by all stream threads, leading to unnecessary concurrency and potential transaction issues.