[Messenger] Add consumer strategy for poll mechanism of receivers #44294
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When using Symfony messenger to consume messages, the default behaviour is to poll each receiver in order. If a receiver has returned messages that were handled, the loop starts to poll the first receiver again. With a comment at the logic stating:
Which makes sense, if you have high and low priority receivers. But I've often found the need for equal polling of receivers, when they don't have different priorities. In that case it is not desired to keep receiving from the first receiver as long as it is returning messages. But to poll each receiver in order.
A random order could also be beneficial for load-balancing. E.g. If you have 2 consumers polling the same receivers in order, and they'd start at the same time, the receivers that are last to be polled will have a handling delay. Until the consumers happen to diverge. But if the order of receivers is randomized, each receiver would likely have less delays between polling.
A
--strategy=priority|ordered|random
command option (and worker option) could expose this as a feature. I'm curious about the thoughts on this.I have not yet added a changelog line (or tests) as I'd first like to get input on this idea as a concept.