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

Feature - Bulk Messaging #95

Open
brutaldev opened this issue Apr 6, 2017 · 2 comments
Open

Feature - Bulk Messaging #95

brutaldev opened this issue Apr 6, 2017 · 2 comments
Labels

Comments

@brutaldev
Copy link

The current implementations of messaging use message pumps with callbacks which is not as efficient as bulk requesting in some circumstances. High volume scenarios should be bulk fetching to reduce costs as well since you are charged per request.

Publish and subscribe should ideally have corresponding bulk overload/versions as well.

@niemyjski
Copy link
Member

Yes, queues also need bulk actions. Would you be willing to submit a pr / have a discussion on this? Ideally the interfaces would just have the bulk implementations and then we have overloads that just call into the bulk versions. I think one of the issues with bulk receiving is we have a greater chance of losing messages from the brokers if we go down with our configuration we use now (we prefer speed currently).

@ejsmith
Copy link
Contributor

ejsmith commented Apr 10, 2017

We definitely want batch dequeue as well. That is why we have queue message locks and timeouts.

@niemyjski niemyjski added the Hacktoberfest Hacktoberfest label Oct 2, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants