3 ms·

Technically Lambda polls SQS (minimum 5 pollers when used as an event source for Lambda). But you don't have to think too much about it. It's mostly important

by kondro 4y ago

Technically Lambda polls SQS (minimum 5 pollers when used as an event source for Lambda). But you don't have to think too much about it. It's mostly important to remember when you're wondering why your mostly-empty queue is still costing you $0.26/month, even if you've got the receive message timeout set to 20 seconds.

jack335 4y ago
Exactly. SQS is a queue where a message resides. Lambda basically polls this message. But like kondro said basically it doesn't matter (directly). I think it is important to understand the event source mapping takes over the polling. But in the end it looks like a push system. But the whole point about costs with empty queues is important. It is definitely important to understand if you want to customize queues for example with long polling. This parameter changes the time your lambda will poll from your queue
philliphaydon 4y ago
Sure but it’s transparent. You don’t need to go write all that logic, against every queue, with possible bugs, handle different scenarios, etc. You just need to write the logic to process the message passed to the lambda. Under the hood it might be polling. But it gives the illusion it’s push and it’s bloody useful.
dkdbejwi383 4y ago
If you use this though, you should be aware that the Lambda-SQS polling mechanism doesn't know about the concurrent execution limits for lambda. If you have set a limit on concurrent executions for your function, or are at the account-level limit, the Lambda-SQS polling mechanism will continue to poll for messages and invoke functions even if execution would fail. This will increment the receive count, and if you have set a limit on the receive count, you may find you drop messages or send them to the DLQ when your handler function hasn't yet had a chance to try and process a given message.
- cloakandswagger 4y ago
  The Lambda-SQS poller will slow down in response to the lambda's error rate for this exact reason. Note that this can cause issues: say you have a time sensitive application that receives a batch of "bad" messages which cause failed lambda invocations. The poller will slow down and the throughput will drop drastically, even though your intention might be for the lambda to continue processing at the same rate and power through the bad messages. This behavior can be disabled with a support request.

by kondro 4y ago

jack335 4y ago

Exactly. SQS is a queue where a message resides. Lambda basically polls this message. But like kondro said basically it doesn't matter (directly). I think it is important to understand the event source mapping takes over the polling. But in the end it looks like a push system. But the whole point about costs with empty queues is important. It is definitely important to understand if you want to customize queues for example with long polling. This parameter changes the time your lambda will poll from your queue

philliphaydon 4y ago

Sure but it’s transparent. You don’t need to go write all that logic, against every queue, with possible bugs, handle different scenarios, etc. You just need to write the logic to process the message passed to the lambda. Under the hood it might be polling. But it gives the illusion it’s push and it’s bloody useful.

dkdbejwi383 4y ago

If you use this though, you should be aware that the Lambda-SQS polling mechanism doesn't know about the concurrent execution limits for lambda. If you have set a limit on concurrent executions for your function, or are at the account-level limit, the Lambda-SQS polling mechanism will continue to poll for messages and invoke functions even if execution would fail. This will increment the receive count, and if you have set a limit on the receive count, you may find you drop messages or send them to the DLQ when your handler function hasn't yet had a chance to try and process a given message.

cloakandswagger 4y ago
The Lambda-SQS poller will slow down in response to the lambda's error rate for this exact reason. Note that this can cause issues: say you have a time sensitive application that receives a batch of "bad" messages which cause failed lambda invocations. The poller will slow down and the throughput will drop drastically, even though your intention might be for the lambda to continue processing at the same rate and power through the bad messages. This behavior can be disabled with a support request.