Messenger Download Apk
Uwe Müller
Messenger provides a message bus with the ability to send messages and thenhandle them immediately in your application or send them through transports(e.g. queues) to be handled later. To learn more deeply about it, read theMessenger component docs.
Messenger centers around two different classes that you'll create: (1) a messageclass that holds data and (2) a handler(s) class that will be called when thatmessage is dispatched. The handler class will read the message class and performone or more tasks.
A message handler is a PHP callable, the recommended way to create it is tocreate a class that has the AsMessageHandlerattribute and has an __invoke() method that's type-hinted with themessage class (or a message interface):
You can also use the #[AsMessageHandler] attribute on individual classmethods. You may use the attribute on as many methods in a single class as youlike, allowing you to group the handling of multiple related types of messages.
Thanks to autoconfiguration and the SmsNotificationtype-hint, Symfony knows that this handler should be called when an SmsNotificationmessage is dispatched. Most of the time, this is all you need to do. But you canalso manually configure message handlers. Tosee all the configured handlers, run:
By default, messages are handled as soon as they are dispatched. If you wantto handle a message asynchronously, you can configure a transport. A transportis capable of sending messages (e.g. to a queueing system) and thenreceiving them via a worker. Messenger supportsmultiple transports.
Thanks to this, the App\Message\SmsNotification will be sent to the asynctransport and its handler(s) will not be called immediately. Any messages notmatched under routing will still be handled immediately, i.e. synchronously.
You may use a partial PHP namespace like 'App\Message\*' to match allthe messages within the matching namespace. The only requirement is that the'*' wildcard has to be placed at the end of the namespace.
The only drawback is that '*' will also apply to the emails sent with theSymfony Mailer (which uses SendEmailMessage when Messenger is available).This could cause issues if your emails are not serializable (e.g. if they includefile attachments as PHP resources/streams).
If you configure routing for both a child and parent class, both rulesare used. E.g. if you have an SmsNotification object that extendsfrom Notification, both the routing for Notification andSmsNotification will be used.
You can define and override the transport that a message is using atruntime by using theTransportNamesStamp onthe envelope of the message. This stamp takes an array of transportname as its only argument. For more information about stamps, seeEnvelopes & Stamps.
If you need to pass a Doctrine entity in a message, it's better to pass the entity'sprimary key (or whatever relevant information the handler actually needs, like email,etc.) instead of the object (otherwise you might see errors related to the Entity Manager):
If a message doesn't match any routing rules, it won'tbe sent to any transport and will be handled immediately. In some cases (likewhen binding handlers to different transports),it's easier or more flexible to handle this explicitly: by creating a synctransport and "sending" messages there to be handled immediately:
The first argument is the receiver's name (or service id if you routed to acustom service). By default, the command will run forever: looking for new messageson your transport and handling them. This command is called your "worker".
In a development environment and if you're using the Symfony CLI tool,you can configure workers to be automatically run along with the webserver.You can find more information in theSymfony CLI Workers documentation.
Sometimes certain types of messages should have a higher priority and be handledbefore others. To make this possible, you can create multiple transports and routedifferent messages to them. For example:
Some transports (notably AMQP) have the concept of exchanges and queues. A Symfonytransport is always bound to an exchange. By default, the worker consumes from allqueues attached to the exchange of the specified transport. However, there are usecases to want a worker to only consume from specific queues.
Supervisor is a great tool to guarantee that your worker process(es) isalways running (even if it closes due to failure, hitting a message limitor thanks to messenger:stop-workers). You can install it on Ubuntu, forexample, via:
Supervisor configuration files typically live in a /etc/supervisor/conf.ddirectory. For example, you can create a new messenger-worker.conf filethere to make sure that 2 instances of messenger:consume are running at alltimes:
During a deployment, something might be unavailable (e.g. thedatabase) causing the consumer to fail to start. In this situation,Supervisor will try startretries number of times to restart thecommand. Make sure to change this setting to avoid getting the commandin a FATAL state, which will never restart again.
Each restart, Supervisor increases the delay by 1 second. For instance, ifthe value is 10, it will wait 1 sec, 2 sec, 3 sec, etc. This gives theservice a total of 55 seconds to become available again. Increase thestartretries setting to cover the maximum expected downtime.
If you use the Redis Transport, note that each worker needs a unique consumername to avoid the same message being handled by multiple workers. One way toachieve this is to set an environment variable in the Supervisor configurationfile, which you can then refer to in messenger.yaml(see the ref:`Redis section ` below):
In some cases the SIGTERM signal is sent by Supervisor itself (e.g. stoppinga Docker container having Supervisor as its entrypoint). In these cases youneed to add a stopwaitsecs key to the program configuration (with a valueof the desired grace period in seconds) in order to perform a graceful shutdown:
While Supervisor is a great tool, it has the disadvantage that you need systemaccess to run it. Systemd has become the standard on most Linux distributions,and has a good alternative called user services.
PHP is designed to be stateless, there are no shared resources across differentrequests. In HTTP context PHP cleans everything after sending the response, soyou can decide to not take care of services that may leak memory.
On the other hand, it's common for workers to process messages sequentially inlong-running CLI processes which don't finish after processing a single message.Beware about service states to prevent information and/or memory leakage asSymfony will inject the same instance of a service in all messages, preservingthe internal state of the services.
However, certain Symfony services, such as the Monologfingers crossed handler, leak by design.Symfony provides a service reset feature to solve this problem. When resettingthe container automatically between two messages, Symfony looks for any servicesimplementing ResetInterface (including yourown services) and calls their reset() method so they can clean their internal state.
When a rate limiter is configured on a transport, it will block the wholeworker when the limit is hit. You should make sure you configure a dedicatedworker for a rate limited transport to avoid other transports to be blocked.
If an exception is thrown while consuming a message from a transport it willautomatically be re-sent to the transport to be tried again. By default, a messagewill be retried 3 times before being discarded orsent to the failure transport. Each retrywill also be delayed, in case the failure was due to a temporary issue. All ofthis is configurable for each transport:
Sometimes handling a message must fail in a way that you know is temporaryand must be retried. If you throwRecoverableMessageHandlingException,the message will always be retried infinitely and max_retries setting will be ignored.
In this example, if handling a message fails 3 times (default max_retries),it will then be sent to the failed transport. While you can usemessenger:consume failed to consume this like a normal transport, you'llusually want to manually view the messages in the failure transport and chooseto retry them:
Sometimes it is not enough to have a single, global failed transport configuredbecause some messages are more important than others. In those cases, you canoverride the failure transport for only specific transports:
If you want to use TLS/SSL encrypted AMQP, you must also provide a CA certificate.Define the certificate path in the amqp.cacert PHP.ini setting(e.g. amqp.cacert = /etc/ssl/certs) or in the cacert parameter of theDSN (e.g amqps://localhost?cacert=/etc/ssl/certs/).
By default, the transport will automatically create any exchanges, queues andbinding keys that are needed. That can be disabled, but some functionalitymay not work correctly (like delayed queues).To not autocreate any queues, you can configure a transport with queues: [].
The consumers do not show up in an admin panel as this transport does not rely on\AmqpQueue::consume() which is blocking. Having a blocking receiver makesthe --time-limit/--memory-limit options of the messenger:consume command as well asthe messenger:stop-workers command inefficient, as they all rely on the fact thatthe receiver returns immediately no matter if it finds a message or not. The consumeworker is responsible for iterating until it receives a message to handle and/or until oneof the stop conditions is reached. Thus, the worker's stop logic cannot be reached if itis stuck in a blocking call.
If your application faces socket exceptions or high connection churn(shown by the rapid creation and deletion of connections), consider usingAMQProxy. This tool works as a gateway between Symfony Messenger and AMQP server,maintaining stable connections and minimizing overheads (which also improvesthe overall performance).
The datetime property of the messages stored in the database uses thetimezone of the current system. This may cause issues if multiple machineswith different timezone configuration use the same storage.
03c5feb9e7