symfony-messenger | Bridge to use Symfony Messenger on AWS Lambda with Bref | AWS library
kandi X-RAY | symfony-messenger Summary
kandi X-RAY | symfony-messenger Summary
Bridge to use Symfony Messenger on AWS Lambda with Bref. This bridge allows messages to be dispatched to SQS, SNS or EventBridge, while workers handle those messages on AWS Lambda.
Support
Quality
Security
License
Reuse
Top functions reviewed by kandi - BETA
- Send an envelope .
- Handle the SQS event .
- Creates an instance of the given DSN .
- Puts an envelope on a bus .
- Handle SNS event .
- Load services .
- Handle an event bridge bridge .
- Reject an envelope
- Returns true if the given DSN is supported .
symfony-messenger Key Features
symfony-messenger Examples and Code Snippets
MESSENGER_TRANSPORT_DSN=https://sqs.us-east-1.amazonaws.com/123456789/my-queue
# serverless.yml
service: my-app
provider:
name: aws
environment:
...
MESSENGER_TRANSPORT_DSN: ${construct:jobs.queueUrl}
constructs:
jobs:
# "myapp" is the EventBridge "source", i.e. a namespace for your application's messages
# This source name will be reused in `serverless.yml` later.
MESSENGER_TRANSPORT_DSN=eventbridge://myapp
MESSENGER_TRANSPORT_DSN=eventbridge://myapp?event_bus_na
MESSENGER_TRANSPORT_DSN=sns://arn:aws:sns:us-east-1:1234567890:foobar
functions:
worker:
handler: bin/consumer.php
timeout: 20 # in seconds
reservedConcurrency: 5 # max. 5 messages processed in parallel
layers:
Community Discussions
Trending Discussions on symfony-messenger
QUESTION
We are using Symfony Messenger in combination with supervisor running in a Docker container on AWS ECS. We noticed the worker is not shut down gracefully. After debugging it appears it does work as expected when using APP_ENV=dev
, but not when APP_ENV=prod
.
I made a simple sleepMessage, which sleeps for 1 second and then prints a message for 60 seconds. This is when running with APP_ENV=dev
As you can see it's clearly waiting for the program to stop running.
Now with APP_ENV=prod
:
It stops immediately without waiting.
In the Dockerfile we have configured the following to start supervisor. It's based on php:8.1-apache
, so that's why STOPSIGNAL has been configured
ANSWER
Answered 2022-Apr-04 at 07:26Turns out it was related to the wait_time
option related to SQS transports. It probably caused a request that was started just before the container exited and was sent back when the container did not exist anymore. So, wait_time
to 0 fixed that problem.
Then there was this which could lead to the same issue
Community Discussions, Code Snippets contain sources that include Stack Exchange Network
Vulnerabilities
No vulnerabilities reported
Install symfony-messenger
Symfony is installed
Symfony Messenger is installed
Bref is installed and configured to deploy Symfony
Support
Reuse Trending Solutions
Find, review, and download reusable Libraries, Code Snippets, Cloud APIs from over 650 million Knowledge Items
Find more librariesStay Updated
Subscribe to our newsletter for trending solutions and developer bootcamps
Share this Page