[9.x] Add unique locking to broadcast events #43416
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
In the test case the lock is successfully acquired after queueing the event, which shouldn't be possible if the lock was acquired. Looks like this isn't a complete solution yet. |
|
@DougSisk any thoughts here? |
|
It seems like since the broadcast manager doesn't use a dispatcher it's pushing right onto the queue. I'm guessing the best option would be to acquire the lock within |
Ken-vdE
pushed a commit
to Ken-vdE/framework
that referenced
this pull request
Aug 9, 2022
* Add unique locking to broadcast events * Don't require uniqueId, set default * Locking irrelevant when broadcasting now * formatting Co-authored-by: Taylor Otwell <taylor@laravel.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Queueing broadcast events is incredibly important, especially at scale. Unfortunately at the moment there is no out-of-the-box method to prevent queues from being overloaded with repeated events. This can lead to redundant broadcast events that eat up data allowances.
I'm proposing a new
Illuminate\Contracts\Broadcasting\ShouldBeUniquecontract that tells the dispatcher to use a separateUniqueBroadcastEventclass. If nouniqueIdmethod or property is defined, the event's class name is used as the identifier. You can also setuniqueForanduniqueVialike other unique queue jobs via a property or method.