Skip to content
This repository has been archived by the owner on Apr 1, 2024. It is now read-only.

ISSUE-13408: PIP-124: Create init subscription before sending message to DLQ #3452

Closed
sijie opened this issue Dec 20, 2021 · 0 comments
Closed
Labels

Comments

@sijie
Copy link
Member

sijie commented Dec 20, 2021

Original Issue: apache#13408


Motivation

If we enable the DLQ when consuming messages. For some messages that can't be processed successfully, the messages will be moved to the DLQ, but if we do not specify the data retention for the namespace or create a subscription for the DLQ to retain the data, the data of the DLQ topic will be removed automatically. Therefore, we need to create the initial subscription before sending messages to the DLQ.

Goal

Users can set the initial subscription name in the DeadLetterPolicy. The consumer will create the initial subscription before sending messages to the DLQ. At this point, subsequent messages produced to the DLQ are not automatically deleted unexpectedly.

This PIP needs to be compatible with the previous behavior. The initial subscription name in the DeadLetterPolicy is optional. Default value is the subscription name of the consumer.

API Changes

Add initSubscriptionName to the DeadLetterPolicy

/**
 * Name of the initial subscription name of the dead letter topic.
 * The default value is the subscription name of the consumer.
 */
private String initSubscriptionName;

Implementation

Before the deadLetterProducer is initialized, the consumer first tries to create a deadLetterConsumer using the initial subscription name in the DeadLetterPolicy. When this subscription already exists, the ConsumerBusy exception will occur. In this case, we can ignore that exception and create the deadLetterProducer.

Prototype implementation PR: apache#13355

@sijie sijie added the PIP label Dec 20, 2021
@sijie sijie closed this as completed Feb 14, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

1 participant