Specifying delivery delays per subscription

[fshafiee]

Is your enhancement request related to a problem? Please describe.
I am unable to setup delayed deliveries per subscription. In other words, the current approach to delaying messages does not conform to following diagram (taken from official docs).

This diagram suggests that delayed messages are tracked per subscription. However, it seems that the delay can only be set by producer.

producer.newMessage().deliverAfter(3L, TimeUnit.Minute).value("Hello Pulsar!").send();

This, IMO, is a contradiction in the design, as the producer in bound a topic, while the delay tracker is bound to a subscription.

This poses a problem to pull-based (as opposed to push-based) architectures, where producers are not aware of the consumption logic (producers are just announcers). There might be many different logics that are bound to the same message topic, some of them may need to be delayed, some may not. It's the consumer (subscription to be exact) that knows whether the messages should be delayed or not, as the diagram correctly suggests.

Describe the solution you'd like
It'd be nice to be able to configure a default delay per subscription. The subscription delay can be overridden using per message delay.

Describe alternatives you've considered
In order to emulate the desired behavior, the consumer has to receive every message and then dispatch them to a retry topic. This introduces unnecessary processing overhead, assuming that delayed deliveries are in fact tracked per subscription which makes pulsar capable to handling this internally.

[tisonkun]

Closed as stale and no one worked on it. Please open a new issue if it's still relevant to the maintained versions.