thetumbled commented on code in PR #24020:
URL: https://github.com/apache/pulsar/pull/24020#discussion_r1977054847
##########
pip/pip-409.md:
##########
@@ -33,25 +33,88 @@ retry/dead letter topic.
## Design & Implementation Details
-- Add two new configurations in `DeadLetterPolicy`:
+- Add `ProducerBuilderContext` and `ProducerBuilderCustomizer` interface:
+```java
+public interface ProducerBuilderContext {
+ /**
+ * Returns the default name of topic for the dead letter or retry letter
producer. This topic name is used
+ * unless the ProducerBuilderCustomizer overrides it.
+ *
+ * @return a {@code String} representing the input topic name
+ */
+ String getDefaultTopicName();
+
+ /**
+ * Returns the name of the input topic for which the dead letter or retry
letter producer is being configured.
+ *
+ * @return a {@code String} representing the input topic name
+ */
+ String getInputTopicName();
+
+ /**
+ * Returns the name of the subscription for which the dead letter or retry
letter producer is being configured.
+ *
+ * @return a {@code String} representing the subscription name
+ */
+ String getInputTopicSubscriptionName();
+}
+
+public interface ProducerBuilderCustomizer {
+ /**
+ * Customize the given producer builder with settings specific to the
topic context provided.
+ *
+ * @param context the context containing information about the
input topic and the subscription
+ * @param producerBuilder the producer builder instance to be customized
+ */
+ void customize(ProducerBuilderContext context, ProducerBuilder<byte[]>
producerBuilder);
Review Comment:
I don't know which kind of senerio need to use a different Pulsar client.
Take the example you mentioned above:
> This would be a way to support different use cases. If you'd replace the
builder, you could even produce to a different cluster with a producer builder
created from a different pulsar client.
Producing the retry messages to another cluster will break the logical
design of retry topic. Let's explain it in more detail. User use `client1` to
create consumer for `inputTopic` and `retryTopic`, both of them belonging to
`cluster1`. But user use `client2` belonging to `cluster2` to create the
producer for `retryTopic`, resulting the message produced to `cluster2`.
However, the consumer for `retryTopic` in `cluster1` can't receive any
messages, which break the logic design completely.
--
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]
