Chapters

48 Chapters | 5:05:05 |

01

Installing Messenger

6:15
02

Message, Handler & the Bus

8:36
03

Doing Work in the Handler

6:32
04

Message, Handler & debug:messenger

5:51
05

Transport: Do Work Later (Async)

7:33
06

Worker Command

5:34
07

Problems with Entities in Messages

4:53
08

Passing Entity Ids inside of Messages

8:00
09

Dispatching a Message inside a Handler?

5:30
10

Partial Handler Failures & Advanced Routing

4:35
11

Envelopes & Stamps

6:23
12

Retrying on Failure

5:11
13

Retry Delay & Retry Strategy

4:40
14

The Failure Transport

5:37
15

Investigating & Retrying Failed Messages

5:41
16

Middleware

5:59
17

Tracking Messages with Middleware & a Stamp

5:31
18

Logger Channel Setup and Autowiring

5:26
19

Middleware Message Lifecycle Logging

7:47
20

High Priority Transports

5:40
21

Handling Messages Sync while Developing

5:54
22

Functional Test for the Upload Endpoint

9:22
23

Testing with the "in-memory" Transport

5:26
24

Deployment & Supervisor

9:08
25

Killing Workers Early & on Deploy

5:55
26

Events & Event Bus

5:22
27

Creating & Handling Events

7:55
28

Dispatching the Event & No Handlers

7:06
29

Messenger vs EventDispatcher

3:18
30

Doctrine Transaction & Validation Middleware

5:58
31

Event & Command Bus Organization

7:23
32

Query Bus

8:47
33

Advanced Handler Config: Handler Subscribers

7:58
34

Sending Handlers to Different Transports: from_transport

3:21
35

AMQP with RabbitMQ

7:22
36

AMQP Internals: Exchanges & Queues

8:10
37

AMQP Priority Exchange

7:15
38

Delaying in AMQP: Dead Letter Exchange

7:23
39

Exchange Routing and Binding Keys

6:38
40

Dynamic AMQP Routing Key (AmqpStamp)

7:50
41

Serializing Messages as JSON

6:41
42

JSON, Message Headers & Serializer Options

3:15
43

Setup for Messages from an Outside System

6:01
44

Transport for Consuming External Messages

5:51
45

Custom Transport Serializer

6:33
46

The Lifecycle of a Message & its Stamps

8:16
47

Graceful Failure in the Transport Serializer

4:47
48

Mapping Messages to Classes in a Transport Serializer

4:56

> Symfony 5 > Messenger! Queue work for Later

Buy Access to Course

21.

Handling Messages Sync while Developing

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!

I love the ability to defer work for later by sending messages to a transport. But, there is at least one practical bummer: it makes it a bit harder to actually develop and code your app. In addition to setting up your web server, database and anything else, you now need to remember to run:

php bin/console messenger:consume

Otherwse... things won't fully work. If you have a robust setup for local development - maybe something using Docker - you could build this right into that setup so that it runs automatically. Except... you'd still need to remember to restart the worker any time you make a change to some code that it uses.

It's not the worst thing ever. But, if this drives you crazy, there is a really nice solution: tell Messenger to handle all of your messages synchronously when you're in the dev environment.

Hello "sync" Transport

Check out config/packages/messenger.yaml. One of the commented-out parts of this file is a, kind of, "suggested" transport called sync. The really important part isn't the name sync but the DSN: sync://. We learned earlier that Messenger supports several different types of transport like Doctrine, redis and AMQP. And the way you choose which one you want is the beginning of the connection string, like doctrine://. The sync transport is really neat: instead of truly sending each message to an external queue... it just handles them immediately. They're handled synchronously.

Making the Transports sync

We can take advantage of this and use a configuration trick to change our async and async_priority_high transports to use the sync:// transport only when we're in the dev environment.

Go into the config/packages/dev directory. Any files here are only loaded in the dev environment and override all values from the main config/packages directory. Create a new file called messenger.yaml... though the name of this file isn't important. Inside, we'll put the same configuration we have in our main file: framework, messenger, transports. Then override async and set it to sync://. Do the same for async_priority_high: set it to sync://.

            Copy Code

                        6 lines
            |
            config/packages/dev/messenger.yaml
        
            framework:
        
                messenger:
        
                    transports:
        
                        async: 'sync://'
        
                        async_priority_high: 'sync://'

That's it! In the dev environment, these values will override the dsn values from the main file. And, we can see this: in an open terminal tab, run:

php bin/console debug:config framework messenger

This command shows you the real, final config under framework and messenger. And... yea! Because we're currently in the dev environment, both transports have a dsn set to sync://.

I do want to mention that the queue_name option is something that's specific to Doctrine. The sync transport doesn't use that, and so, it ignores it. It's possible that in a future version of Symfony, this would throw an error because we're using an undefined option for this transport. If that happens, we would just need to change the YAML format to set the dsn key - like we do in the main messenger.yaml file - and then override the options key and set it to an empty array. I'm mentioning that just in case.

Ok, let's try this! Refresh the page to be safe. Oh, and before we upload something, go back to the terminal where our worker is running, hit Control+C to stop it, and restart it. Woh! It's busted!

You cannot receive messages from the sync transport.

Messenger is saying:

Yo! Um... the SyncTransport isn't a real queue you can read from... so stop trying to do it!

It's right... and this is exactly what we wanted: we wanted to be able to have our handlers called in the dev environment without needing to worry about running this command.

Ok, now let's try it: upload a couple of photos and... yea... it's super slow again. But Ponka is added when it finishes. The messages are being handled synchronously.

To make sure this is only happening for the dev environment, open up the .env file and change APP_ENV to be prod temporarily. Make sure to clear your cache so this works:

php bin/console cache:clear

Now, we should be able to run messenger:consume like before:

php bin/console messenger:consume -vv async_priority_high async

And... we can! Sync messages in dev, async in prod.

Now that we've accomplished this, change APP_ENV back to dev and, just to keep things more interesting for the tutorial, comment out the new sync config we just added: I want to continue using our real transports while we're coding. Stop and restart the worker:

            Copy Code

                        6 lines
            |
            config/packages/dev/messenger.yaml
        
            framework:
        
                messenger:
        
            #        transports:
        
            #            async: 'sync://'
        
            #            async_priority_high: 'sync://'

Now that we're back in the dev environment, stop and restart the worker:

php bin/console messenger:consume -vv async_priority_high async

Next: let's talk about a similar problem: how do you handle transports when writing automated tests?

4 Comments

Sort By

amcastror 4 years ago edited

Hi there , thanks for this series, it's very good.

I have a question dough.. What do you think would be the correct approach to dynamically change if a message should be handled in the sync or async transport? I have a message that can be dispatched in a cronjob or in a controller. In the cronjob I want it to be handled sync and in the controller async.

Thanks a lot!

| Reply |

MolloKhan SFCASTS amcastror 4 years ago edited

Hey Matias C.

There is a way to configure your handler so they can decide which transport to use. Check out this chapter https://symfonycasts.com/screencast/messenger/from-transport

but based on your situation I'd just execute the handler directly in my cronjob command e.g.


// SomeCommand.php

public function __construct(SomeHandler $someHandler)
{
    $this->someHandler = $someHandler;
}

protected function execute(Input $input, Output $output) 
{
    // execute the __invoke method of this handler
    ($this->someHandler)(
        new SomeMessage($argument);
    );
}

Cheers!

| Reply |

amcastror MolloKhan 4 years ago

Hi @MolloKhan thanks for the answer.

Cool thing calling the handler directly, I hadn't thought of that.

On the other hand, the chapter you sent me it's not about choosing transport, but choosing handlers (right?). The handler decides wether to execute or not depending on the transport the message has been sent to.

I'm still confused about how to programmatically route a message to one or another transport. I was browsing the code and there's a HandlersLocatorInterface that looks promising, but I can't find any documentation about it. I can see that there's a compiler pass that configures a HandlersLocator with the yaml configuration, but nothing more.

It would be cool to use a stamp to define which handler to use.. does it make any sense?

Cheers!

| Reply |

MolloKhan SFCASTS amcastror 4 years ago edited

Hey Matias C.

Yes, you're right, that's only for choosing which transport to use. I was looking for a solution to your problem and couldn't find anything buit-in. What you can do is to create your own stamp and transport. In the sender you will check if the envelope has such stamp and then decide which transport to use
Here you can read how to create a custom Transport https://symfony.com/doc/cur...

Cheers!

| Reply |

This tutorial is built with Symfony 4.3, but will work well on Symfony 4.4 or 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

Handling Messages Sync while Developing

Share this awesome video!

Keep on Learning!

Hello "sync" Transport

Making the Transports sync

4 Comments

Delete comment?

What PHP libraries does this tutorial use?

	framework:
	messenger:
	transports:
	async: 'sync://'
	async_priority_high: 'sync://'

	framework:
	messenger:
	# transports:
	# async: 'sync://'
	# async_priority_high: 'sync://'