Closed garygitton closed 9 years ago
Hi,
That sounds like an interesting idea. Actually in SQS the better solution would be to use the "WaitTimeSeconds" attribute to keep long-polling (http://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html).
However this approach can work on any queue system, so maybe it's better to use it here. @juriansluiman @basz ?
sure, seems very similar to, but more generic then https://github.com/juriansluiman/SlmQueueDoctrine/blob/master/src/SlmQueueDoctrine/Strategy/IdleNapStrategy.php though.
When complete, please add documentation describing the strategy's usage at : https://github.com/juriansluiman/SlmQueue/blob/master/docs/6.Events.md#provided-worker-strategies
@bakura10 yes but there is a slight difference with "waitTimeSecond" because it defines the long polling time which is limited to 20s by SQS. It means that the lowest frequency we can have is 0.05. With this strategy we can imagine doing a pool every minute or every hour if we want.
I agree I should not have put it by default. I will change that. Also, I will remove the case where max frequency is 0 as we dont activate this strategy by default.
Thanks for the advices.
Did you close this by mistake ?
My mistake, you reopened a pr. You do not need to do thar just to update the code ;)
Oupst! je ne savais pas, merci pour l'info ;)
Haha on s'en sortirait pas si on devait créer une nouvelle PR à chaque modification ;)
Hey,
I'm using this module with the extension SlmQueue SQS. In 5 days, this module did 5 millions requests. Far too much compare to my needs and also its includes a cost.
So I created a strategy to limit the max polling frequency.
When frequency is set to 0, it means that the strategy dont operate. When frequency is at 0.1, this process the queue every 10 seconds.