README.md in lambda_punch-0.0.8 vs README.md in lambda_punch-1.0.0
- old
+ new
@@ -70,27 +70,39 @@
end
```
### ActiveJob
-🚧 COMING SOON 🚧 - A simple ActiveJob adapter...
+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.**
+```ruby
+config.active_job.queue_adapter = :lambda_punch
+```
+
### Timeouts
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.
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.
-**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.**
+**For a more robust background job solution, please consider using AWS SQS with the [Lambdakiq](https://github.com/customink/lambdakiq) gem.**
### Logging
The default log level is `error`, so you will not see any LambdaPunch lines in your logs. However, if you want some low level debugging information on how LambdaPunch is working, you can use this environment variable to change the log level.
```yaml
Environment:
Variables:
LAMBDA_PUNCH_LOG_LEVEL: debug
+```
+
+### Errors
+
+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.
+
+```ruby
+LambdaPunch.error_handler = lambda { |e| ... }
```
## 📊 CloudWatch Metrics
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