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] Add a "in-memory://" transport#29097

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
fabpot merged 2 commits intosymfony:masterfromGaryPEGEOT:feature/null-transporter
Apr 6, 2019
Merged

[Messenger] Add a "in-memory://" transport#29097

fabpot merged 2 commits intosymfony:masterfromGaryPEGEOT:feature/null-transporter
Apr 6, 2019

Conversation

@GaryPEGEOT
Copy link
Contributor

@GaryPEGEOTGaryPEGEOT commentedNov 5, 2018
edited
Loading

QA
Branch?master
Bug fix?no
New feature?yes
BC breaks?no
Deprecations?no
Tests pass?yes
Fixed tickets#29040
LicenseMIT
Doc PRTodo

Add a newInMemoryTransport for test purpose, usable by starting your DSN byin-memory://

julienj, bigfoot90, and andreybolonin reacted with thumbs up emoji
@ogizanagi
Copy link
Contributor

ogizanagi commentedNov 5, 2018
edited
Loading

Just a random thought: Isn't a null transport just a special case of amemory transport without any listener?

yceruto and ostrolucky reacted with thumbs up emoji

@ogizanagi
Copy link
Contributor

Note regarding#29097 (comment): that would mean making the MemoryTransportMessageBusInterface $bus constructor argument optional or extract dispatch in a dedicated listener.
No strong opinion yet.

@nicolas-grekasnicolas-grekas added this to thenext milestoneNov 6, 2018
@javiereguiluz
Copy link
Member

@GaryPEGEOT thanks for this contribution! If this is finally merged, please review thelist of Messenger issues andlist of pending Messenger pull requests to see if there are issues/PRs conflicting with this change. If there are not, please open an issue inhttps://github.com/symfony/symfony-docs/issues to track this change. You don't have to provide the docs yourself if you don't want, but this would help us track the change. Thanks!

Copy link
Contributor

@srozesroze left a comment

Choose a reason for hiding this comment

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

Except these stylish details to be changed, looks good to me 👍

@stof
Copy link
Member

Just a random thought: Isn't a null transport just a special case of amemory transport without any listener?

If you never flush your MemoryTransport, it would leak memory. So using it instead of a NullTransport looks wrong (having to flush something when you expect it to be a blackhole is not intuitive)

*/
publicfunctionsend(Envelope$envelope):Envelope
{
$this->sent[] =$envelope;
Copy link
Member

Choose a reason for hiding this comment

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

As we accumulate envelopes over time, do we need to implementResetableInterface to flush the envelopes from one request to the next?

ogizanagi and sroze reacted with thumbs up emoji
Copy link
ContributorAuthor

Choose a reason for hiding this comment

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

@sroze,@fabpot I've implementedSymfony\Contracts\Service\ResetInterface and I now see that there is anack anreject method in the Transport interface. Do you think we need to store which message has been ack / nack?

@ogizanagi
Copy link
Contributor

ogizanagi commentedMar 21, 2019
edited
Loading

having to flush something when you expect it to be a blackhole is not intuitive)

But it's not just a blackhole (null transport might be misleading in this way): this transport is storing the sent envelopes (to be used in tests for instance). So I would have implementedResetableInterface on theMemoryTransport and just use a different factory registering it.

@sroze
Copy link
Contributor

@GaryPEGEOT can you implement theResetableInterface and test that the messages are properly removed?

@sroze
Copy link
Contributor

sroze commentedMar 23, 2019 via email

Indeed, it would make sense.
On Sat, 23 Mar 2019 at 22:48, Gary PEGEOT ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In src/Symfony/Component/Messenger/Transport/NullTransport.php <#29097 (comment)>: > + } + + /** + * ***@***.***} + */ + public function stop(): void + { + $this->stopped = true; + } + + /** + * ***@***.***} + */ + public function send(Envelope $envelope): Envelope + { + $this->sent[] = $envelope;@sroze <https://github.com/sroze>,@fabpot <https://github.com/fabpot> I've implemented Symfony\Contracts\Service\ResetInterface and I now see that there is an ack an reject method in the Transport interface. Do you think we need to store which message has been ack / nack? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#29097 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAxHEZUH-p7C_wteK6h840k5Nr_c8SPSks5vZkzOgaJpZM4YOsl_> .

@GaryPEGEOT
Copy link
ContributorAuthor

@sroze I added thegetAcknowledged andgetRejected methods

*
* @author Gary PEGEOT <garypegeot@gmail.com>
*/
class NullTransportimplements TransportInterface, ResetInterface
Copy link
Contributor

@ogizanagiogizanagiMar 23, 2019
edited
Loading

Choose a reason for hiding this comment

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

Note implementingResetInterface isn't enough for this to be properly integrated with the framework and stored envelopes to be cleared from one request to the next. The service definition must be tagged withkernel.reset.

But as the service is built using a factory and might use an env var for the DSN, it may not be possible to add the tag conditionally from the extension (compile time). Instead, you could implement ResetInterface on the factory too and keep track of created services to clear them from here (so only the factory will be tagged withkernel.reset).

sroze reacted with thumbs up emoji
*
* @author Gary PEGEOT <garypegeot@gmail.com>
*/
class NullTransportFactoryTestextends \PHPUnit\Framework\TestCase
Copy link
Contributor

Choose a reason for hiding this comment

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

maybe worth importing TestCase?
use PHPUnit\Framework\TestCase;

@fabpot
Copy link
Member

I agree with@ogizanagi that I would not expect anull transport to store things.

@sroze
Copy link
Contributor

in-memory://?

@weaverryan
Copy link
Member

Well, we also have#28746, which is a "memory" transport where the messages are sent onkernel.terminate. Probably we should only merge one... call itmemory:// (?), and have the "send on kernel.terminate` part configurable, so that you could use it for testing (and not handle on kernel.terminate) or decide that you DO want to send it using that.

@sroze
Copy link
Contributor

I agree it should be the same implementation. Though... it could actually be two DSNsin-memory:// &symfony://kernel.terminate IMHO. Let's make this one justin-memory:// and ask thekernel.terminate to be changed to update this transport. WDYT?

ogizanagi reacted with thumbs up emoji

@GaryPEGEOT
Copy link
ContributorAuthor

Should it be a black-hole and do nothing at all (no storing nor receiving of message) to avoid duplication with memory listener?

@sroze
Copy link
Contributor

to avoid duplication with memory listener

What do you mean? 🤔

@GaryPEGEOT
Copy link
ContributorAuthor

to avoid duplication with memory listener

What do you mean? thinking

memorytransport, my bad!, both this transport and the one in#28746 store message in memory, so are kind of duplicate. Should this one donothing instead, ie not storing any message?

@weaverryan
Copy link
Member

I think the idea is this: This one SHOULD store in memory, and be calledin-memory. And then#28746 could actually use this transport behind the scenes to read the stored messages and send them.

@sroze
Copy link
Contributor

Exactly 👍

@GaryPEGEOT
Copy link
ContributorAuthor

I think the idea is this: This one SHOULD store in memory, and be calledin-memory. And then#28746 could actually use this transport behind the scenes to read the stored messages and send them.

Renamed toInMemoryTransport, as well as the dsn

@GaryPEGEOTGaryPEGEOT changed the title[Messenger] Add a "null://" transport[Messenger] Add a "in-memory://" transportMar 31, 2019
useSymfony\Contracts\Service\ResetInterface;

/**
* Transport that stay in memory. Useful for testing purpose.
Copy link
Member

Choose a reason for hiding this comment

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

stays

@fabpot
Copy link
Member

Thank you@GaryPEGEOT.

@fabpotfabpot merged commit8f8c82e intosymfony:masterApr 6, 2019
fabpot added a commit that referenced this pull requestApr 6, 2019
…, sroze)This PR was merged into the 4.3-dev branch.Discussion----------[Messenger] Add a "in-memory://" transport| Q             | A| ------------- | ---| Branch?       | master| Bug fix?      | no| New feature?  | yes| BC breaks?    | no| Deprecations? | no| Tests pass?   | yes| Fixed tickets |#29040| License       | MIT| Doc PR        | TodoAdd a new `InMemoryTransport` for test purpose, usable by starting your DSN by `in-memory://`Commits-------8f8c82e Make the in-memory transport resettablefe75920 Add a "null://" transport
Copy link
Member

@NyholmNyholm left a comment

Choose a reason for hiding this comment

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

Thank you

#eu-fossa

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@fabpotfabpotfabpot approved these changes

@NyholmNyholmNyholm left review comments

@chalasrchalasrchalasr approved these changes

+5 more reviewers

@webignitionwebignitionwebignition left review comments

@OcramiusOcramiusOcramius left review comments

@srozesrozesroze approved these changes

@ogizanagiogizanagiogizanagi 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.

14 participants

@GaryPEGEOT@ogizanagi@javiereguiluz@stof@sroze@fabpot@weaverryan@webignition@Ocramius@Nyholm@onEXHovia@chalasr@nicolas-grekas@carsonbot

[8]ページ先頭

©2009-2025 Movatter.jp