Skip to content
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 for delayed message delivery #2375

Closed
kesavkolla opened this issue Aug 15, 2018 · 12 comments · Fixed by #4062
Closed

Support for delayed message delivery #2375

kesavkolla opened this issue Aug 15, 2018 · 12 comments · Fixed by #4062
Labels
area/client type/feature The PR added a new feature or issue requested a new feature
Milestone

Comments

@kesavkolla
Copy link

Scheduled and delayed message delivery is a good feature to support in pulsar. Basically individual message can have a header which will be set by publisher and based on the header value the broker should hold message in queue. Upon the interval is over message should be delivered to subscribers

@sijie sijie added area/client type/feature The PR added a new feature or issue requested a new feature labels Aug 15, 2018
@sijie sijie added this to the 2.2.0-incubating milestone Aug 15, 2018
@codelipenghui
Copy link
Contributor

Is any idea to implement this feature? I'm interest to join the discussion of design and contribute for this feature.

@skyrocknroll
Copy link
Contributor

This is an excellent feature we heavily depend on the current messaging system.

@pmwqld
Copy link

pmwqld commented Oct 23, 2018

We would like to use such a feature to implement an AUTO Dead Letter Queue (DLQ). Any messages that cannot be processed from the main topic can be sent to the AUTO DLQ topic and only become "visible" after a particular time depending on the retry and backoff algorithm.

@codelipenghui
Copy link
Contributor

@pmwqld

We would like to use such a feature to implement an AUTO Dead Letter Queue (DLQ). Any messages that cannot be processed from the main topic can be sent to the AUTO DLQ topic and only become "visible" after a particular time depending on the retry and backoff algorithm.

I think if all messages with the same delay time in the topic, use Dead Letter Queue can match this scene. otherwise the dispatcher logic in broker and limited by the receive queue will affect the delay result.

@codelipenghui
Copy link
Contributor

codelipenghui commented Nov 21, 2018

Delayed message redelivery solution based on expose redelivery count to client. #3030

@Ah39
Copy link

Ah39 commented Nov 21, 2018

mark ,the feature have finished ??

@codelipenghui
Copy link
Contributor

@Ah39 PR #3033

@sijie
Copy link
Member

sijie commented Nov 21, 2018

@Ah39 it is not completed yet. there is an ongoing PIP for it.

@skyrocknroll
Copy link
Contributor

Getdelivery count does not cover all the use cases. We are pushing the logic to determine whether the delay has expired to the client(Implementing this in all the client languages will be repetitive & some language clients may not even get this feature implemented). If the broker sends the message to the client after the expiry of the delay then it would be simple and straightforward to remember.

@skyrocknroll
Copy link
Contributor

@sijie is there any link to the PIP definition to share?

@sijie
Copy link
Member

sijie commented Nov 22, 2018

@sijie
Copy link
Member

sijie commented Nov 22, 2018

PIP-26: https://github.com/apache/pulsar/wiki/PIP-26:-Delayed-Message-Delivery

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/client type/feature The PR added a new feature or issue requested a new feature
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants