Skip to content
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

[Mesenger] Add support for reseting container services between 2 messages #41163

Merged
merged 1 commit into from Sep 10, 2021

Conversation

lyrixx
Copy link
Member

@lyrixx lyrixx commented May 10, 2021

Q A
Branch? 5.4
Bug fix? no
New feature? yes
Deprecations? no
Tickets
License MIT
Doc PR symfony/symfony-docs#15796

Without this patch, services are not resetted. For example Monolog
Finger Cross handler is never reset nor flushed. So if the first
message trigger and "error" level message, all others message will log
and overflow the buffer.

So, when a transport is async (it means it is run in a worker), it's highly preferable to this configuration on

Usage with framework:

framework:
    messenger:
        transports:
            async:
                dsn: '%env(MESSENGER_TRANSPORT_DSN)%'
                reset_on_message: true
            failed: 'doctrine://default?queue_name=failed'
            sync: 'sync://'

@carsonbot

This comment has been minimized.

@lyrixx
Copy link
Member Author

lyrixx commented Jul 23, 2021

Hello, I have rebased this PR, and addressed all comments. I should be OK now

@lyrixx
Copy link
Member Author

lyrixx commented Sep 1, 2021

I could rebase this PR, but before doing so, I prefer to be sure it's mergeable. so WDYT?

Edit: I have rebased the PR

@Jeroeny
Copy link
Contributor

Jeroeny commented Sep 3, 2021

So if the first message trigger and "error" level message, all others message will log and overflow the buffer.

From my experience, a worker running without processing messages can also go out of memory. For example if you have an app running in debug mode the tracing/profiling will keep event-dispatcher events in memory, eventually causing the process to go out of memory.

Because of this, should there also be a possibility to trigger the reset onWorkerRunning instead of just the WorkerMessageHandledEvent and WorkerMessageFailedEvent ?

And continuing on that, would it be nice if you could do a reset when the worker is inactive (Can be read WorkerRunningEvent->isWorkerIdle()) ? . So that if your reset functionality has a bit of performance impact, it could have less impact on the message handling performance.

@lyrixx
Copy link
Member Author

lyrixx commented Sep 3, 2021

From my experience, a worker running without processing messages can also go out of memory. For example if you have an app running in debug mode the tracing/profiling will keep event-dispatcher events in memory, eventually causing the process to go out of memory.

Indeed, cf #32422

Because of this, should there also be a possibility to trigger the reset onWorkerRunning instead of just the WorkerMessageHandledEvent and WorkerMessageFailedEvent ?

I don't understand :/

And continuing on that, would it be nice if you could do a reset when the worker is inactive (Can be read WorkerRunningEvent->isWorkerIdle()) ? . So that if your reset functionality has a bit of performance impact, it could have less impact on the message handling performance.

Indeed, that would be possible, in a next PR :)

@Jeroeny
Copy link
Contributor

Jeroeny commented Sep 3, 2021

If I understood the logic in this PR correctly, a reset is only triggered by on of those WorkerMessage.. events right? So it's only going to reset if messages are being consumed. What about a worker/consumer that's idle for a while? It could go out of memory for the same reasons and might benefit from reset of its services.

@lyrixx
Copy link
Member Author

lyrixx commented Sep 3, 2021

Ohhh, I see, good point. I need to check when the running event is triggered to ensure it does not break something

@Jeroeny
Copy link
Contributor

Jeroeny commented Sep 3, 2021

when the running event is triggered

I think it should be just as safe as the other events, it at least not during the handling of a message:

https://github.com/symfony/symfony/blob/5.4/src/Symfony/Component/Messenger/Worker.php#L95
https://github.com/symfony/symfony/blob/5.4/src/Symfony/Component/Messenger/Worker.php#L111

@lyrixx
Copy link
Member Author

lyrixx commented Sep 6, 2021

@Jeroeny Here we go 👍🏼 I pushed a new version where the listener listen WorkerRunningEvent too. Thanks for the hint 👍🏼

Copy link
Member

@fabpot fabpot left a comment

Choose a reason for hiding this comment

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

Can you update the description to explain when and why one should enable or disable this flag? If you can create a PR on the docs, that would be the cherry on the cake :)

…ssenger message.

Without this patch, services are not resetted. For example Monolog
Finger Cross handler is never reset nor flushed. So if the first
message trigger and "error" level message, all others message will log
and overflow the buffer.

Usage with framework:

```yaml
framework:
    messenger:
        transports:
            async:
                dsn: '%env(MESSENGER_TRANSPORT_DSN)%'
                reset_on_message: true
            failed: 'doctrine://default?queue_name=failed'
            sync: 'sync://'
```
@lyrixx
Copy link
Member Author

lyrixx commented Sep 10, 2021

@fabpot I haved edited the PR description, and the configuration.
I'll open the doc PR asap (edit: symfony/symfony-docs#15796)

@fabpot
Copy link
Member

fabpot commented Sep 10, 2021

Thank you @lyrixx.

@fabpot fabpot merged commit ba7f746 into symfony:5.4 Sep 10, 2021
@lyrixx lyrixx deleted the worker-reset-on-message branch September 10, 2021 09:45
@@ -195,6 +196,12 @@
->tag('kernel.event_subscriber')

->set('messenger.listener.stop_worker_on_stop_exception_listener', StopWorkerOnCustomStopExceptionListener::class)

Choose a reason for hiding this comment

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

Is it correct that the StopWorkerOnCustomStopExceptionListener service looses the kernel.event_subscriber tag?

Copy link
Member Author

Choose a reason for hiding this comment

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

Thanks, fixed in #43002

fabpot added a commit that referenced this pull request Sep 13, 2021
…rkerOnCustomStopExceptionListener (lyrixx)

This PR was merged into the 5.4 branch.

Discussion
----------

[Messenger] Add back kernel.event_subscriber tag on StopWorkerOnCustomStopExceptionListener

| Q             | A
| ------------- | ---
| Branch?       | 5.4
| Bug fix?      | yes (but the bug was not released)
| New feature?  | no
| Deprecations? | no
| Tickets       |
| License       | MIT
| Doc PR        |

refs:
#41163 (comment)

Commits
-------

00a34c6 [Messenger] Add back kernel.event_subscriber tag on StopWorkerOnCustomStopExceptionListener
symfony-splitter pushed a commit to symfony/framework-bundle that referenced this pull request Sep 13, 2021
…rkerOnCustomStopExceptionListener (lyrixx)

This PR was merged into the 5.4 branch.

Discussion
----------

[Messenger] Add back kernel.event_subscriber tag on StopWorkerOnCustomStopExceptionListener

| Q             | A
| ------------- | ---
| Branch?       | 5.4
| Bug fix?      | yes (but the bug was not released)
| New feature?  | no
| Deprecations? | no
| Tickets       |
| License       | MIT
| Doc PR        |

refs:
symfony/symfony#41163 (comment)

Commits
-------

00a34c623b [Messenger] Add back kernel.event_subscriber tag on StopWorkerOnCustomStopExceptionListener
javiereguiluz added a commit to symfony/symfony-docs that referenced this pull request Oct 4, 2021
…lyrixx)

This PR was squashed before being merged into the 5.4 branch.

Discussion
----------

[Messenger] document reset_on_message transport option

refs symfony/symfony#41163

Commits
-------

3f7ebce [Messenger] document reset_on_message transport option
This was referenced Nov 5, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants