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

42.

JSON, cabeceras de mensajes y opciones del serializador

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!

Además de la carga útil, un mensaje en RabbitMQ también puede tener "cabeceras". Comprueba esa clave en nuestro mensaje. ¡Woh! ¡Contiene una gran estructura JSON con el nombre de la clase original y los datos y nombres de clase de los sellos adjuntos al mensaje!

¿Por qué ha hecho esto Messenger? Bueno, busca tu terminal y consume el transporte async:

php bin/console messenger:consume -vv async

Esto sigue funcionando. Internamente, el serializador de Symfony utiliza la información deheaders para averiguar cómo tomar esta simple cadena JSON y convertirla en el objeto correcto. Utilizó la cabecera type para saber que el JSON debía convertirse en un objetoImagePostDeletedEvent y luego hizo un bucle sobre los sellos y convirtió cada uno de ellos en un objeto sello para el sobre.

Lo bueno de utilizar el serializador de Symfony en Messenger es que el payload es una estructura JSON simple y pura que puede ser consumida por cualquier aplicación en cualquier lenguaje. Contiene algo de información de la clase PHP en las cabeceras, pero otra aplicación puede simplemente ignorar eso. Pero gracias a esas cabeceras, si la misma app envía y consume un mensaje, el serializador Symfony puede seguir utilizándose.

¿No deberíamos utilizar siempre el serializador de Symfony?

Pero espera... si eso es cierto - si el serializador de Symfony crea mensajes que pueden ser consumidos por sistemas externos o por nuestra misma app - entonces ¿por qué no es el serializador por defecto en Messenger? ¡Una excelente pregunta! La razón es que el serializador de Symfony requiere que tus clases sigan algunas reglas para ser serializadas y des-serializadas correctamente - como que cada propiedad necesita un método setter o un argumento constructor donde el nombre coincida con el nombre de la propiedad. Si tu clase no sigue esas reglas, puedes acabar con una propiedad que está establecida en el objeto original, pero que de repente se convierte en nula cuando se lee del transporte. No es divertido.

En otras palabras, el serializador de PHP es más fácil y fiable cuando todo lo hace la misma aplicación.

Configurar el serializador de Symfony

De todos modos, si estás utilizando el serializador de Symfony, también hay algunas cosas que se pueden configurar. Busca tu terminal y ejecuta:

php bin/console config:dump framework messenger

Comprueba la clave symfony_serializer. Aquí es donde configuras el comportamiento del serializador: el formato - json, xml o algo más, y elcontext, que es una matriz de opciones para el serializador.

Por supuesto, también puedes crear un servicio de serializador totalmente personalizado. Y si tienes el flujo de trabajo opuesto al que acabamos de describir -uno en el que tu aplicación consume mensajes que fueron enviados a Rabbit desde algún otro sistema- un serializador personalizado es exactamente lo que necesitas. Hablemos de eso a continuación.

2 Comments

Sort By

Mokhtar T. 3 years ago

Hello Ryan

sorry to put this question here but as part of serializing message from and external service you mentioned that in case we have an invalid message we should throw MessageEncodingException and this one will kill the process of our consumer and supervisor will restart it but by default supervisor has 3 retires so if we have more than 3 invalid message the queue will switch to idle status and our consumer won't working how to prevent that ? I'm thinking to increase supervisor retries but it looks anugly solution do you have any othe idea ? thanks in advance

| Reply |

weaverryan SFCASTS Mokhtar T. 3 years ago edited

Hey Mokhtar T.!

Hmm, that's interesting. So it sounds like you have a situation where it might be normal to receive invalid messages from external services? This wasn't something I've really thought about before. But, if you do have this, I see your point: 3 invalid messages in a row will cause your worker process to fail so rapidly, that you would probably hit the startretries limit. Here's what I'd recommend:

A) If you can, try avoiding this. I know, this seems obvious - and there is probably some reason why you have this situation. But in general, knowing that you may routinely receive invalid messages to your queue seems odd to me.

B) If you can't avoid it, you could set startsecs to 0 to avoid it thinking that the restart was unsuccessful.

C) When you throw an exception during the decoding process, the normal Symfony console error system is invoked. This means that you should be able to listen to this event - https://symfony.com/doc/current/components/console/events.html#the-consoleevents-error-event or https://symfony.com/doc/current/components/console/events.html#the-consoleevents-terminate-event - and... do something... like add a pause (a literal sleep(1) ) so that the process waits long enough before exiting that supervisor knows that it DID start up successfully. A little odd... but I'm not sure if there is anything else you can do from these listeners.

D) If you're writing a custom deserializer, you could, I think, return a dummy Message object that has a handle that... does nothing. In other words, you WOULD always return a valid message object... but if there was a deserialization problem, then it's a dummy message whose handle does nothing.

So... a few "decent" options - I hope this will help.

Cheers!

| Reply |

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
    }
}