@@ -705,14 +705,19 @@ PHP is designed to be stateless, there are no shared resources across different
705
705
requests. In HTTP context PHP cleans everything after sending the response, so
706
706
you can decide to not take care of services that may leak memory.
707
707
708
- On the other hand, workers usually sequentially process messages in long-running CLI processes, which don't
709
- finish after processing a single message. That's why you must be careful about service
710
- states to prevent information and/or memory leakage as Symfony will inject the same instance of a
711
- service, preserving the internal state of the service between messages.
708
+ On the other hand, it's common for workers to process messages sequentially in
709
+ long-running CLI processes which don't finish after processing a single message.
710
+ Beware about service states to prevent information and/or memory leakage as
711
+ Symfony will inject the same instance of a service in all messages, preserving
712
+ the internal state of the services.
712
713
713
714
However, certain Symfony services, such as the Monolog
714
715
:ref: `fingers crossed handler <logging-handler-fingers_crossed >`, leak by design.
715
- That's why Symfony automatically resets the service container between two messages.
716
+ Symfony provides a **service reset ** feature to solve this problem. When resetting
717
+ the container automatically between two messages, Symfony looks for any services
718
+ implementing :class: `Symfony\\ Contracts\\ Service\\ ResetInterface ` (including your
719
+ own services) and calls their ``reset() `` method so they can clean their internal state.
720
+
716
721
If a service is not stateless and you want to reset its properties after each message, then
717
722
the service must implement :class: `Symfony\\ Contracts\\ Service\\ ResetInterface ` where you can reset the
718
723
properties in the ``reset() `` method.
0 commit comments