Skip to content

Commit fd38755

Browse files
committed
Reword
1 parent b74685f commit fd38755

File tree

2 files changed

+16
-11
lines changed

2 files changed

+16
-11
lines changed

logging.rst

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -167,6 +167,8 @@ defined.
167167
from the two files cannot be merged because the order matters and a merge does
168168
not allow to control the order.
169169

170+
.. _logging-handler-fingers_crossed:
171+
170172
Handlers that Modify Log Entries
171173
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
172174

messenger.rst

Lines changed: 14 additions & 11 deletions
Original file line numberDiff line numberDiff line change
@@ -696,22 +696,21 @@ of the desired grace period in seconds) in order to perform a graceful shutdown:
696696
[program:x]
697697
stopwaitsecs=20
698698
699-
700699
Stateless Worker
701700
~~~~~~~~~~~~~~~~
702701

703-
PHP was designed to be stateless: everything is lost after processing an HTTP
704-
request. When you run your application in an HTTP context, you may not take care
705-
of services states that may leak services since PHP clean everything after
706-
sending the response.
702+
PHP is designed to be stateless, there are no shared resources across different
703+
requests. In HTTP context PHP cleans everything after sending the response, so
704+
you can decide to not take care of services that may leak memory.
707705

708-
Since worker run in a CLI context, you need to be careful about services state.
709-
You should avoid to put a state in a service to avoid leaking some information
710-
and/or memory from one message to another message.
706+
On the other hand, workers usually run in long-running CLI processes, which don't
707+
finish after processing a message. That's why you need to be careful about services
708+
state to not leak information and/or memory from one message to another message.
711709

712-
Some symfony services leak by nature. For example the monolog fingers crossed
713-
handler. To avoid such situations, you can configure a transport to
714-
automatically reset the container between two messages:
710+
However, certain Symfony services, such as the Monolog
711+
:ref:`fingers crossed handler <logging-handler-fingers_crossed>`, leak by design.
712+
In those cases, use the ``reset_on_message`` transport option to automatically
713+
reset the service container between two messages:
715714

716715
.. configuration-block::
717716

@@ -759,6 +758,10 @@ automatically reset the container between two messages:
759758
;
760759
};
761760
761+
.. versionadded:: 5.4
762+
763+
The ``reset_on_message`` option was introduced in Symfony 5.4.
764+
762765
.. _messenger-retries-failures:
763766

764767
Retries & Failures

0 commit comments

Comments
 (0)