Chapters

48 Chapters | 5:05:05 |

01

Instalar el Messenger

6:15
02

Mensaje, Manejador y el Bus

8:36
03

Haciendo el trabajo en el controlador

6:32
04

Mensaje, manejador y depuración:messenger

5:51
05

Transporte: Haz el trabajo después (asíncrono)

7:33
06

Comando del trabajador

5:34
07

Problemas con las entidades en los mensajes

4:53
08

Pasar Ids de entidad dentro de los mensajes

8:00
09

¿Despachar un mensaje dentro de un manejador?

5:30
10

Fallos parciales del manejador y enrutamiento avanzado

4:35
11

Sobres y sellos

6:23
12

Reintentar en caso de fallo

5:11
13

Retraso en el reintento y estrategia de reintento

4:40
14

El transporte de fallos

5:37
15

Investigar y reintentar mensajes fallidos

5:41
16

Middleware

5:59
17

Seguimiento de los mensajes con el middleware y un sello

5:31
18

Configuración del canal de registro y autoconexión

5:26
19

Registro del ciclo de vida de los mensajes del middleware

7:47
20

Transportes de alta prioridad

5:40
21

Manejar la sincronización de mensajes mientras se desarrolla

5:54
22

Prueba funcional del punto final de carga

9:22
23

Probando con el transporte "en memoria

5:26
24

Despliegue y supervisión

9:08
25

Matar a los trabajadores antes de tiempo y en el despliegue

5:55
26

Eventos y bus de eventos

5:22
27

Creación y manejo de eventos

7:55
28

Despacho del evento y sin manejadores

7:06
29

Messenger vs EventDispatcher

3:18
30

Middleware de transacción y validación de Doctrine

5:58
31

Organización del bus de eventos y comandos

7:23
32

Autobús turístico

8:47
33

Configuración avanzada del manipulador: Suscriptores del Manejador

7:58
34

Envío de manejadores a diferentes transportes: from_transport

3:21
35

AMQP con RabbitMQ

7:22
36

Aspectos internos de AMQP: Intercambios y colas

8:10
37

Intercambio de prioridades AMQP

7:15
38

Retraso en AMQP: intercambio de letra muerta

7:23
39

Intercambio de Claves de Enrutamiento y Vinculación

6:38
40

Clave de enrutamiento AMQP dinámica (AmqpStamp)

7:50
41

Serializar mensajes como JSON

6:41
42

JSON, cabeceras de mensajes y opciones del serializador

3:15
43

Configuración de los mensajes de un sistema externo

6:01
44

Transporte para consumir mensajes externos

5:51
45

Serializador de transporte personalizado

6:33
46

El ciclo de vida de un mensaje y sus sellos

8:16
47

Fallo Gracioso en el Serializador de Transporte

4:47
48

Asignación de mensajes a clases en un serializador de transporte

4:56

> Symfony 5 > ¡Messenger! Encola el trabajo para Despues

Buy Access to Course

40.

Clave de enrutamiento AMQP dinámica (AmqpStamp)

|

|

Autoplay

Keep on Learning!

If you liked what you've learned so far, dive in! Subscribe to get
access to this tutorial plus video, code and script downloads.

Start your All-Access Pass

Buy just this tutorial for $12.00

Previous Chapter

Next Chapter

With a Subscription, click any sentence in the script to jump to that part of the video!

Login Subscribe

Login or register to check out the script

7 Comments

Sort By

Login or Register to join the conversation

Małgorzata M. 4 years ago

Hi, I'd like to configure a single exchange with multiple queues. I know the way to specify routing_key for the message by adding AmqpStamp directly when publishing a new message, but is there a way to configure it within yml configuration under framework -> messenger -> routing for each message?

Symfony 5.x

|

weaverryan SFCASTS Małgorzata M. 4 years ago

Hey @Anton!

Hmm. I do not believe so, the "framework -> messenger -> routing" config is very simple, just routing to which transport each message class should go. If you'd like to centralize this in some way, one option is via an event listener - I think listening to https://github.com/symfony/... would work. In this listener, you could have logic where you add the AmqpStamp based on the class of the message that is being routed. Or, you could make your messages implement some marker interface, and look for that interface from inside your listener.

Anyways, let me know if this is useful or not :).

Cheers!

|

wtk13 6 years ago

https://stackoverflow.com/q...

|

weaverryan SFCASTS wtk13 6 years ago edited

Hey wtk13!

Sorry for my late reply - I saw how complex your message was and needed to find time to review it. But now I just saw that you seem to have found the answer yourself :). If you still have any questions about it, let me know.

Cheers!

|

Francisc 6 years ago

why is it that even if I send a message already routed to an exchange but with a AmqpStamp/binding key linked with another exchange/queue the message will get routed to the exchange that handles that binding key? Even if this is desired outcome would not be considerate to maybe fire a warning saying that message-exchange-binding_key-route combination is overruled?

I want to know the details of what happens behind messenger/ampq-protocol.

Thanks!

|

weaverryan SFCASTS Francisc 6 years ago edited

Hey Francisc!

Great question :). If you're setting up binding & routing keys like we do in this chapter, you are definitely doing something more advanced and choosing to take more control over the process. For most cases, just "letting Messenger handle it" is the best way. But for some advanced use-cases - and for users that are very familiar with AMQP - this chapter shows how you could take more control.

But let me answer your questions specifically:

why is it that even if I send a message already routed to an exchange but with a AmqpStamp/binding key linked with another exchange/queue the message will get routed to the exchange that handles that binding key?

All of this is a specific to how AMQP works. Apologies if you already know some of this - I just want to give a complete answer.

So first, you are always sending a message to an exchange (not a queue). In this case, both async and async_priority_high are configured to send to the same exchange: messages. AMQP is, sort of, "dumb". When the "messages" exchange receives a message, (because it is a direct exchange) it will look at the "routing key" (e.g. FOO_ROUTING_KEY) of that message and then send it to the 0-to-many queues that have said "Hey! If a FOO_ROUTING_KEY is set on a message, please send to me!". This is called a "binding".

In the Messenger config, each transport that we've configured has one item under "queues". For example:


            async:
                    # ...
                    queues:
                        messages_normal:
                            binding_keys: [normal]

This causes a few things to happen in Messenger:

A) It creates a queue named "messages_normal"
B) It adds a "binding" to the "messages" exchange that says: "If the routing key is 'normal', please send to me".
C) When you "consume": this transport, it will "consume" messages from the "messages_normal" queue.

So ultimately, all of our config will cause 1 exchange to be created and 2 queues to be created, each with one binding key to the one exchange. Phew!

Even if this is desired outcome would not be considerate to maybe fire a warning saying that message-exchange-binding_key-route combination is overruled?

Yes, we could do do that. But at this point, we're doing SUCH custom things with AMQP, that we have to assume you know what you're doing. Heck, it's legal to publish a message with a routing key that corresponds to ZERO "bindings". You might think that this means that the message would get routed to NO queues. And you would be correct. Unless there is some other (3rd party) system that is also creating bindings. That's one of the truly powerful (but complex) things with AMQP: we cannot even assume that our Symfony app is the only thing creating exchanges, queues, publishing keys, etc. So even if the user does something that seems "crazy", they might have a perfectly good reason to do it.

This is all fascinating stuff to learn about it. But until/unless you have a reason to take advanced control over binding & routing keys like this, don't do it ;).

And if I've done a bad job explaining things, please let me know.

Cheers!

|

Francisc weaverryan 6 years ago edited

Thank you weaverryan for the answer, it help! Thank you also for the symfonycasts tutorials, they are really easy to follow and quite funny.

|

Este tutorial está construido con Symfony 4.3, pero funcionará bien en Symfony 4.4 o 5.

Symfony 4.3

What PHP libraries does this tutorial use?

// composer.json
{
    "require": {
        "php": "^7.1.3",
        "ext-ctype": "*",
        "ext-iconv": "*",
        "composer/package-versions-deprecated": "^1.11", // 1.11.99
        "doctrine/annotations": "^1.0", // v1.8.0
        "doctrine/doctrine-bundle": "^1.6.10", // 1.11.2
        "doctrine/doctrine-migrations-bundle": "^1.3|^2.0", // v2.0.0
        "doctrine/orm": "^2.5.11", // v2.6.3
        "intervention/image": "^2.4", // 2.4.2
        "league/flysystem-bundle": "^1.0", // 1.1.0
        "phpdocumentor/reflection-docblock": "^3.0|^4.0", // 4.3.1
        "sensio/framework-extra-bundle": "^5.3", // v5.3.1
        "symfony/console": "4.3.*", // v4.3.2
        "symfony/dotenv": "4.3.*", // v4.3.2
        "symfony/flex": "^1.9", // v1.21.6
        "symfony/framework-bundle": "4.3.*", // v4.3.2
        "symfony/messenger": "4.3.*", // v4.3.4
        "symfony/property-access": "4.3.*", // v4.3.2
        "symfony/property-info": "4.3.*", // v4.3.2
        "symfony/serializer": "4.3.*", // v4.3.2
        "symfony/validator": "4.3.*", // v4.3.2
        "symfony/webpack-encore-bundle": "^1.5", // v1.6.2
        "symfony/yaml": "4.3.*" // v4.3.2
    },
    "require-dev": {
        "easycorp/easy-log-handler": "^1.0.7", // v1.0.7
        "symfony/debug-bundle": "4.3.*", // v4.3.2
        "symfony/maker-bundle": "^1.0", // v1.12.0
        "symfony/monolog-bundle": "^3.0", // v3.4.0
        "symfony/stopwatch": "4.3.*", // v4.3.2
        "symfony/twig-bundle": "4.3.*", // v4.3.2
        "symfony/var-dumper": "4.3.*", // v4.3.2
        "symfony/web-profiler-bundle": "4.3.*" // v4.3.2
    }
}

Previous Chapter

Next Chapter