You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+14-2Lines changed: 14 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -72,15 +72,19 @@ end
72
72
73
73
### ActiveJob
74
74
75
-
🚧 COMING SOON 🚧 - A simple ActiveJob adapter...
75
+
You can use LambdaPunch with Rails' ActiveJob. **For a more robust background job solution, please consider using AWS SQS with the [Lambdakiq](https://github.com/customink/lambdakiq) gem.**
76
+
77
+
```ruby
78
+
config.active_job.queue_adapter =:lambda_punch
79
+
```
76
80
77
81
### Timeouts
78
82
79
83
Your function's timeout is the max amount to handle the request and process all extension's invoke events. If your function times out, it is possible that queued jobs will not be processed until the next invoke.
80
84
81
85
If your application integrates with API Gateway (which has a 30 second timeout) then it is possible your function can be set with a higher timeout to perform background work. Since work is done after each invoke, the LambdaPunch queue should be empty when your function receives the `SHUTDOWN` event. If jobs are in the queue when this happens they will have two seconds max to work them down before being lost.
82
86
83
-
**For a more robust background job solution, please consider using AWS SQS with the [Lambdakiq](https://github.com/customink/lambdakiq) gem. A drop-in replacement for [Sidekiq](https://github.com/mperham/sidekiq) when running Rails in AWS Lambda using the [Lamby](https://lamby.custominktech.com/) gem.**
87
+
**For a more robust background job solution, please consider using AWS SQS with the [Lambdakiq](https://github.com/customink/lambdakiq) gem.**
84
88
85
89
### Logging
86
90
@@ -92,6 +96,14 @@ Environment:
92
96
LAMBDA_PUNCH_LOG_LEVEL: debug
93
97
```
94
98
99
+
### Errors
100
+
101
+
As jobs are worked off the queue, all job errors are simply logged. If you want to customize this, you can set your own error handler.
102
+
103
+
```ruby
104
+
LambdaPunch.error_handler = lambda { |e| ... }
105
+
```
106
+
95
107
## 📊 CloudWatch Metrics
96
108
97
109
When using Extensions, your function's CloudWatch `Duration` metrics will be the sum of your response time combined with your extension's execution time. For example, if your request takes `200ms` to respond but your background task takes `1000ms` your duration will be a combined `1200ms`. For more details see the _"Performance impact and extension overhead"_ section of the [Lambda Extensions API
0 commit comments