alexsapps commented on issue #12053: URL: https://github.com/apache/pulsar/issues/12053#issuecomment-951395768
I was able to answer most of the questions myself after reading the original PR that introduced the feature - [6449](https://github.com/apache/pulsar/pull/6449/files). > Is it really the producer's responsibility to send the message to the retry topic? ... No. It’s the consumer’s responsibility to call reconsumeLater to effectively move the message to the retry queue upon failing to process a message. > ... does the consumer get both business and retry messages in the same stream ... Yes, the consumer implementation automatically subscribes itself to the retry topic as well as the original topic. Still not sure about prioritization or interleaving. > What is the relationship between retryLetterTopic and enableRetry? enableRetry must be turned on explicitly to enable retries. retryLetterTopic is only used for customizing the retry topic name; if not set a default retry letter topic name is used. Similarly for dead letter topic name. > What is "retrial queue" (reconsumeLater) ? Is it different than a retry topic? Pretty sure it’s the same. Didn’t see any special “retrial queue” in the code. > Is reconsumeLater different from throwing an exception that causes the message to go to the retryLetterTopic? Still not sure. > What is maxRedeliverCount – is “redeliver” different from “retry”? ... Redeliver and retry seem to be interchangeable here. It’s the number of times it goes into the retry queue before dead letter topic. > ... configure the delay time ... reconsumeLater accepts a delay time that can be different each time it’s called. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
