-
Notifications
You must be signed in to change notification settings - Fork 3.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support Consumers Set Custom Retry Delay #6449
Support Consumers Set Custom Retry Delay #6449
Conversation
@liudezhi2098 Thanks for the great work. Would you please help add some tests for it? |
/pulsarbot run-failure-checks |
/pulsarbot run-failure-checks |
045771b
to
68b425d
Compare
/pulsarbot run-failure-checks |
This doc update is for the PR: apache#6449
Doc has been added #7151 |
propertiesMap.put(RetryMessageUtil.SYSTEM_PROPERTY_DELAY_TIME, String.valueOf(unit.toMillis(delayTime))); | ||
|
||
if (reconsumetimes > this.deadLetterPolicy.getMaxRedeliverCount()) { | ||
processPossibleToDLQ((MessageIdImpl)messageId); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does anyone know what is the point of this line? The logic of sending message to dead letter queue is described within more than twenty lines below as well as message acknowledgment, why is it done twice?
@liudezhi2098 Hi, could you please comment on my question above? |
<!-- ### Contribution Checklist - Name the pull request in the form "[Issue XYZ][component] Title of the pull request", where *XYZ* should be replaced by the actual issue number. Skip *Issue XYZ* if there is no associated github issue for this pull request. Skip *component* if you are unsure about which is the best component. E.g. `[docs] Fix typo in produce method`. - Fill out the template below to describe the changes contributed by the pull request. That will give reviewers the context they need to do the review. - Each pull request should address only one issue, not mix up code from multiple issues. - Each commit in the pull request has a meaningful commit message - Once all items of the checklist are addressed, remove the above text and this checklist, leaving only the filled out template below. **(The sections below can be removed for hotfixes of typos)** --> Master Issue: apache#6448 ### Motivation For many online business systems, various exceptions usually occur in business logic processing, so the message needs to be re-consumed, but users hope that this delay time can be controlled flexibly. The current user's processing method is usually to send this message to a special retry topic, because production can specify any delay, so consumers subscribe the business topic and retry topic at the same time. I think this logic can be supported by pulsar itself, making it easier for users to use, and it looks like this is a very common requirement. ### Modifications This change can be supported on the client side, need to add a set of interfaces to org.apache.pulsar.client.api.Consumer ```java void reconsumeLater(Message<?> message, long delayTime, TimeUnit unit) throws PulsarClientException; CompletableFuture<Void> reconsumeLaterAsync(Message<?> message, long delayTime, TimeUnit unit); CompletableFuture<Void> reconsumeLaterAsync(Messages<?> messages, int delayLevel); ``` DeadLetterPolicy add retry topic ```java public class DeadLetterPolicy { /** * Maximum number of times that a message will be redelivered before being sent to the dead letter queue. */ private int maxRedeliverCount; /** * Name of the retry topic where the failing messages will be sent. */ private String retryLetterTopic; /** * Name of the dead topic where the failing messages will be sent. */ private String deadLetterTopic; } ``` org.apache.pulsar.client.impl.ConsumerImpl add a retry producer ```java private volatile Producer<T> deadLetterProducer; private volatile Producer<T> retryLetterProducer; ``` Can specify whether to enable retry when creating a consumer,default unenable ```java @OverRide public ConsumerBuilder<T> enableRetry(boolean retryEnable) { conf.setRetryEnable(retryEnable); return this; } ```
### Motivation This PR is to update doc for the PR: apache#6449 Doc contents have been approved by the previous PR apache#7151. Because there are two many conflicts in that PR. So I close the original PR and re-create this PR. ### Modifications Add retry letter topic in concept> messaging doc.
### Motivation Follow [pulsar#6449](apache/pulsar#6449) to support retry letter topic in go client ### Modifications - Add `retryRouter` for sending reconsume messages to retry letter topic - Add `ReconsumeLater(msg Message, delay time.Duration)` to Consumer interface - Add configureable retry letter topic name in `DLQPolicy` ```go type DLQPolicy struct { // ... // Name of the topic where the retry messages will be sent. RetryLetterTopic string } ``` enable it explicitly while creating consumer, default unenable ```go type ConsumerOptions struct { // ... // Auto retry send messages to default filled DLQPolicy topics RetryEnable bool } ``` - Add 2 `TestRLQ*` test cases
Master Issue: #6448
Motivation
For many online business systems, various exceptions usually occur in business logic processing, so the message needs to be re-consumed, but users hope that this delay time can be controlled flexibly. The current user's processing method is usually to send this message to a special retry topic, because production can specify any delay, so consumers subscribe the business topic and retry topic at the same time. I think this logic can be supported by pulsar itself, making it easier for users to use, and it looks like this is a very common requirement.
Modifications
This change can be supported on the client side, need to add a set of interfaces to org.apache.pulsar.client.api.Consumer
DeadLetterPolicy add retry topic
org.apache.pulsar.client.impl.ConsumerImpl add a retry producer
Can specify whether to enable retry when creating a consumer,default unenable