-
Notifications
You must be signed in to change notification settings - Fork 437
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
Avoid receiveNoWait when only one subscriber #626
Conversation
public function __construct() | ||
{ | ||
$this->subscribers = []; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
please revert the change
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, but just curious what it's done this way? CS?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
could you please rename timeout argument to |
Done |
Thank you @deguif ! |
You're welcome. |
This follows #625 I created yesterday
Let's try to explain the issue with further details.
This occurs when using AWS SQS as queue system.
The SQS context doesn't support
SubscriptionConsumer
and throws an exception when calling itscreateSubscriptionConsumer()
method. This exception is then caught and is replaced by the fallback subscription consumer.The
FallbackSubscriptionConsumer
is a basic implementation which loops over a list of subscribers and call on each of them theirreceiveNoWait()
method.This is a cost killer for AWS SQS as this will query for new messages without polling.
Here's an example of the command I run and which leads to this dramatic cost:
php bin/console enqueue:transport:consume --time-limit=+80seconds --receive-timeout=20000 --idle-timeout=5000 MyApp\Processor
This command is run by a supervising system which rerun it once it stops (reached its time limit).
And here's my proposed solution, which avoids calling
receiveNoWait()
when there is only one subscriber in the fallback subscription consumer.This is not a full fix as this won't avoid this cost killing when passing multiple subscribers to the fallback subscription consumer.