Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork9.7k
Allow a zero time-limit for messenger:consume#44931
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
micheh commentedJan 6, 2022
Why don't you add |
stof commentedJan 6, 2022 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
@micheh that's a legitimate question. But to me, the PR still makes sense. |
fritzmg commentedJan 6, 2022 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
Using only |
OskarStark commentedJan 8, 2022
While I am fine with this PR, wouldn't time-limit=1 and limit=1 work for you? The usage of time-limit=0 could be confusing? Why not add an option --stop-immediately or sth more explanatory? |
fritzmg commentedJan 8, 2022
Not to an engineer? ;) |
GromNaN commentedJan 8, 2022
Thank you@fritzmg. |
Uh oh!
There was an error while loading.Please reload this page.
By default
messenger:consumewill run indefinitely and as the docs mention you should monitor the process via Supervisor for example. However on shared hostings this is usually not an option and thus this command will be run via a cronjob there (at least I assume that's the intended best practise in such a case). To ensure the worker exits for each cronjob run, you can use the--time-limitoption, e.g.However, this would allow the worker to consume multiple message for the duration of 1000ms - so technically if you want the worker toimmediately exit each time after it processed the current message queue it should actually be
But this does not currently work, as the zero is falsey and thus the
StopWorkerOnTimeLimitListenerwill not actually be added.This PR fixes that by checking whether the option was actually supplied or not.