Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

[Messenger] Adding MessageCountAwareInterface to get transport message count#30757

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

Merged

Conversation

@weaverryan
Copy link
Member

QA
Branch?master
Bug fix?no
New feature?yes
BC breaks?no
Deprecations?no
Tests pass?yes
Fixed ticketsnone
LicenseMIT
Doc PRsymfony/symfony-docs#11236

This adds a new optional interface that receivers should implement to give an approximate number of the messages "waiting" to be handled. Why? Because, with this, you could design a system that dynamically adds/removes worker processes if a specific transport is getting slammed and needs help. Creating that system could be something we discuss for core later, but this at least makes it possible - and means it could be implemented by the user or in a bundle... which I might do if we don't get it in core ;).

vincenttouzet and orangevinz reacted with thumbs up emoji
@sroze
Copy link
Contributor

I don't think we should add it to the core without knowing the actually use-case tbh.

@nicolas-grekasnicolas-grekas added this to thenext milestoneMar 31, 2019
@weaverryanweaverryanforce-pushed themessenger-receiver-count branch 3 times, most recently fromdc21b88 toadda867CompareMarch 31, 2019 16:26
@weaverryan
Copy link
MemberAuthor

I don't think we should add it to the core without knowing the actually use-case tbh.

Very fair. So, let me try to be more specific... even though I admit, I'm "planning ahead" a bit here. One easy thing to look at is Larave's Horizon, which takes advantage of the "size" of a queue for (A) displaying a health dashboard and (B) for automatically spinning up/down more/less workers for each transport, based on the size. Without this feature (which is pretty simple), creating something like that as a 3rd party bundle, for example, will not be possible.

Rebased and comments addressed!

@weaverryanweaverryanforce-pushed themessenger-receiver-count branch 2 times, most recently fromb7a472b todecd53fCompareMarch 31, 2019 17:19
@weaverryan
Copy link
MemberAuthor

@vincenttouzet could you check the Doctrine part of this PR out? There is an integration test, but would love your +1 technically for it.

Copy link
Contributor

@vincenttouzetvincenttouzet left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Except the comment on the fetch / fetchColumn this looks good to me and very promising !

@weaverryanweaverryanforce-pushed themessenger-receiver-count branch 2 times, most recently from7292b2b toacddcaeCompareApril 1, 2019 15:33
@nicolas-grekasnicolas-grekas changed the title[Messenger] Adding MessageCountAwareReceiverInterface to get transport message count[Messenger] Adding MessageCountAwareInterface to get transport message countApr 3, 2019
Copy link
Member

@nicolas-grekasnicolas-grekas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

(it'd be nice updating the 1st commit message with the new name of the interface)

@fabpotfabpotforce-pushed themessenger-receiver-count branch fromacddcae tofc5b0cfCompareApril 3, 2019 14:45
@fabpot
Copy link
Member

Thank you@weaverryan.

@fabpotfabpot merged commitfc5b0cf intosymfony:masterApr 3, 2019
fabpot added a commit that referenced this pull requestApr 3, 2019
…ransport message count (weaverryan)This PR was squashed before being merged into the 4.3-dev branch (closes#30757).Discussion----------[Messenger] Adding MessageCountAwareInterface to get transport message count| Q             | A| ------------- | ---| Branch?       | master| Bug fix?      | no| New feature?  | yes| BC breaks?    | no| Deprecations? | no| Tests pass?   | yes| Fixed tickets | none| License       | MIT| Doc PR        |symfony/symfony-docs#11236This adds a new optional interface that receivers should implement to give an approximate number of the messages "waiting" to be handled. Why? Because, with this, you could design a system that dynamically adds/removes worker processes if a specific transport is getting slammed and needs help. Creating that system could be something we discuss for core later, but this at least makes it possible - and means it could be implemented by the user or in a bundle... which I might do if we don't get it in core ;).Commits-------fc5b0cf [Messenger] Adding MessageCountAwareInterface to get transport message count

$sender->send($first =newEnvelope(newDummyMessage('First')));
$sender->send($second =newEnvelope(newDummyMessage('Second')));
$sender->send($second =newEnvelope(newDummyMessage('Third')));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

🤔

OskarStark reacted with laugh emoji
Copy link
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

@weaverryanweaverryan deleted the messenger-receiver-count branchApril 4, 2019 11:28
@nicolas-grekasnicolas-grekas modified the milestones:next,4.3Apr 30, 2019
@fabpotfabpot mentioned this pull requestMay 9, 2019
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@OskarStarkOskarStarkOskarStark left review comments

@fabpotfabpotfabpot approved these changes

@nicolas-grekasnicolas-grekasnicolas-grekas approved these changes

@srozesrozeAwaiting requested review from sroze

+3 more reviewers

@ro0NLro0NLro0NL left review comments

@vincenttouzetvincenttouzetvincenttouzet left review comments

@onEXHoviaonEXHoviaonEXHovia left review comments

Reviewers whose approvals may not affect merge requirements

Assignees

No one assigned

Projects

None yet

Milestone

4.3

Development

Successfully merging this pull request may close these issues.

9 participants

@weaverryan@sroze@fabpot@nicolas-grekas@OskarStark@ro0NL@vincenttouzet@onEXHovia@carsonbot

[8]ページ先頭

©2009-2025 Movatter.jp