-
-
Notifications
You must be signed in to change notification settings - Fork 9.5k
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
[Console] Add ability to schedule alarm signals and a ConsoleAlarmEvent
#53533
Conversation
ecb03f9
to
baaf070
Compare
src/Symfony/Component/Console/Command/SignalableCommandInterface.php
Outdated
Show resolved
Hide resolved
src/Symfony/Component/Console/Command/AlarmableCommandInterface.php
Outdated
Show resolved
Hide resolved
a11d0da
to
93f7c17
Compare
93f7c17
to
e42a38a
Compare
src/Symfony/Component/Console/Command/AlarmableCommandInterface.php
Outdated
Show resolved
Hide resolved
src/Symfony/Component/Console/Command/AlarmableCommandInterface.php
Outdated
Show resolved
Hide resolved
src/Symfony/Component/Console/Tests/phpt/alarm/command_exit.phpt
Outdated
Show resolved
Hide resolved
3496c6f
to
26d9c59
Compare
26d9c59
to
4ff3662
Compare
Btw, So if a command logic f.e. includes Another (old) thing I found that using |
4ff3662
to
16b0fd9
Compare
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.
cc @chalasr
we're running a userland implementation in prod, it works fine
d0507cd
to
5c32d9c
Compare
AlarmableCommandInterface
and console.alarm
eventconsole.alarm
event
if (!$this->signalRegistry) { | ||
throw new RuntimeException('Unable to subscribe to signal events. Make sure that the "pcntl" extension is installed and that "pcntl_*" functions are not disabled by your php.ini\'s "disable_functions" directive.'); | ||
} | ||
$signalRegistry = $this->getSignalRegistry(); |
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.
getSignalRegistry
throws a nearly identical exception, so it made sense to me to have it centralized.
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.
The implementation is now much simpler, looks good to me 👍
5c32d9c
to
1c70c98
Compare
33fb7b7
to
5541f00
Compare
console.alarm
eventConsoleAlarmEvent
5541f00
to
33f049c
Compare
33f049c
to
97e4391
Compare
Thank you @HypeMC. |
…which messages are still being processed (HypeMC) This PR was merged into the 7.2 branch. Discussion ---------- [Console][Messenger] Asynchronously notify transports which messages are still being processed | Q | A | ------------- | --- | Branch? | 7.2 | Bug fix? | no | New feature? | yes | Deprecations? | no | Issues | - | License | MIT Certain transports, such as Beanstalkd, have a timeout that determines how long a certain message is considered as "in progress". If the message is not acknowledged or rejected within that time period, it is returned to the "ready" queue. This could cause potential issues when it takes a handler longer to finish processing the message. In those instances, the message being processed could be returned to the ready queue and taken by another instance of the receiver. This would result in the message being processed multiple times, or even worse, in an infinite loop. Usually, transports that have a timeout also have the option to be notified that the message is still being processed, so the timeout can be postponed. The idea of this PR is to utilize the `SignalableCommandInterface` and `pcntl_alarm()` to notify transports which messages are still being processed. Since the `SignalRegistry` has [asynchronous signals enabled](https://github.com/symfony/symfony/blob/34915f6e16f04537eb18d9d2c303ec375e63cc4b/src/Symfony/Component/Console/SignalRegistry/SignalRegistry.php#L21) by default, the whole process would happen asynchronously. I've named this feature "keepalive" for lack of a better name. Currently, I've added this option only to the Beanstalkd transport since that's the one I'm familiar with and use, but as far as I was able to gather, at least one other transport supports this feature. Amazon SQS has a visibility timeout which can be [increased](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-visibility-timeout.html#changing-message-visibility-timeout). This visibility timeout seems to be the same thing as Beanstalkd's TTR. (Disclaimer: I've never used Amazon SQS, so if I got something wrong, please let me know.) I've split the PR into two commits so it would (hopefully) be easier to review: 1. I've extracted the first commit into a separate PR: #53533 2. The second commit adds the keepalive feature to the Messenger component. Commits ------- 57b556a [Messenger] Notify transports which messages are still being processed, using `pcntl_alarm()`
Thanks for working on this @HypeMC! |
Part of #53508
This PR introduces the ability to schedule alarm signals and a
console.alarm
event. A command using this feature will automatically dispatch an alarm at the specified interval:The
console.alarm
event is dispatched on everySIGALRM
signal: