Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[Messenger] DLX configuration issue #30218

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
bentcoder opened this issue Feb 12, 2019 · 7 comments
Closed

[Messenger] DLX configuration issue #30218

bentcoder opened this issue Feb 12, 2019 · 7 comments
Labels
Bug Messenger Status: Needs Review

Comments

@bentcoder
Copy link

Symfony version(s) affected: 4.2.2

Hi,

Since there is no single entry in the documentation around AMQP Dead Letter Exchange, I am asking to find out if this is a bug or not. If it is an expected behaviour then please answer the question below. Much appreciated.

I am trying to automatically configure DLX exchange image_crop_dlx_ex and a queue image_crop_dlx_qu to go with it. However, they don't seem to be created in RabbitMQ unlike others (image_crop_ex and image_crop_qu). See the configuration below please.

All I want to do is:

  • Have image_crop_dlx_ex and image_crop_dlx_qu in RabbitMQ.
  • Reject a message in the handler so that it goes DLX.

Configuration

framework:
    messenger:
        transports:
            amqp_image_crop_dlx: # This section seems to be ignored
                dsn: 'amqp://rabbitmq:[email protected]:5672/%2f/'
                options:
                    exchange:
                        name: image_crop_dlx_ex
                        type: fanout
                    queue:
                        name: image_crop_dlx_qu
            amqp_image_crop: # This section gets created automatically which is perfect
                dsn: 'amqp://rabbitmq:[email protected]:5672/%2f/'
                options:
                    exchange:
                        name: image_crop_ex
                        type: fanout
                    queue:
                        name: image_crop_qu
                        arguments:
                            x-dead-letter-exchange: image_crop_dlx_ex
                            x-message-ttl: 86400

        routing:
            'App\MessageBus\Message\Image\Crop': amqp_image_crop

Message Dispacher

namespace App\Service;

use App\MessageBus\Message\Image\Crop;
use Symfony\Component\Messenger\MessageBusInterface;

class CropService
{
    private $messageBus;

    public function __construct(MessageBusInterface $messageBus)
    {
        $this->messageBus = $messageBus;
    }

    public function crop(): void
    {
        $message = new Crop('ball.png');

        $this->messageBus->dispatch($message);
    }
}

Message

namespace App\MessageBus\Message\Image;

class Crop
{
    private $path;

    public function __construct(string $path)
    {
        $this->path = $path;
    }

    public function getPath(): string
    {
        return $this->path;
    }
}

Message Handler

namespace App\MessageBus\Handler\Image;

use App\MessageBus\Message\Image\Crop;
use Symfony\Component\Messenger\Handler\MessageHandlerInterface;

class CropHandler implements MessageHandlerInterface
{
    public function __invoke(Crop $message)
    {
        if ($message->getPath() === 'bad_image.jpeg') {
                // How do I reject the message here so that it ends up in DLX ?
                // Important: The running terminal command below should carry on running.
        }

        // Otherwise, I'll crop the file here
    }
}

Terminal Command

$ bin/console messenger:consume-messages amqp_image_crop
@bentcoder bentcoder mentioned this issue Feb 12, 2019
Closed
@hoebelix
Copy link

You can reject a message by throwing an exception which implements RejectMessageExceptionInterface (see the loop in https://github.com/symfony/messenger/blob/master/Transport/AmqpExt/AmqpReceiver.php). In my opinion there should be a configuration option whether only exceptions implementing RejectMessageExceptionInterface should cause a rejection (as it is now) or whether other or all exceptions should cause a rejection.

Why? For example, when there is an exception in the standard serializer (obviously not implementing RejectMessageExceptionInterface), the message gets requeued, effectively leading to an infinite loop.

@bentcoder
Copy link
Author

I've done the exception bit you mentiomed before but there are two problems with it:

  • It caises the terminal commamd to die so messages are not consumed anymore.
  • Rejected message won't go to DLX because it doesn't exist as I mentioned above.

@hoebelix
Copy link

First problem: The terminal command should not run a long time anyway. I have wrapped it in a systemd service which is restarted automatically when it dies.

Second problem: Yes, that is true.

@bentcoder
Copy link
Author

First problem: The terminal command should not run a long time anyway. I have wrapped it in a systemd service which is restarted automatically when it dies.

I agree with that and I mentioned it somewhere here but cannot remember where so the command should take an argument to say max how many job it should process rather than running forever. Then it is developer's responsibility to bring it back up with a process controller such as supervisord etc.

@sroze
Copy link
Contributor

sroze commented Mar 19, 2019

@bentcoder the amqp_image_crop_dlx is ignored because the transport is not used. #29476 will allow you to run a command to "force-setup" all the transports, this should solve your issue.

@sroze sroze mentioned this issue Mar 27, 2019
Merged
@bentcoder
Copy link
Author

This issue is to be solved by #29476

@sroze
Copy link
Contributor

sroze commented Mar 31, 2019

As it's merged, let's close this issue :)

@sroze sroze closed this as completed Mar 31, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Bug Messenger Status: Needs Review
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@sroze @xabbuh @bentcoder @carsonbot @hoebelix