README.md in atomic-sidekiq-1.0.0 vs README.md in atomic-sidekiq-1.1.0
- old
+ new
@@ -1,5 +1,7 @@
+[](https://badge.fury.io/rb/atomic-sidekiq) [](https://travis-ci.org/Colex/atomic-sidekiq) [](https://codecov.io/gh/Colex/atomic-sidekiq)
+
# AtomicSidekiq
AtomicSidekiq implements a reliable way of processing jobs using Sidekiq. By default, Sidekiq will retrieve jobs from the queue by removing it from Redis. If the job fails to complete (e.g. the process terminates unexpectdly mid-job), the job will be lost forever. This can be acceptable in many applications, but some application require higher levels of reliability, hence AtomicSidekiq will not erase any job from Redis until it's acknowledged that they have finished - otherwise, they are re-scheduled.
The algorithm used by AtomicSidekiq supports both queue prioritization mechanisms: strict priority and weighted random.
@@ -24,9 +26,26 @@
Sidekiq.configure_server do |config|
config.atomic_fetch!({
collection_interval: 5, # Unit: seconds
expiration_time: 1800 # Unit: seconds (30 minutes)
})
+end
+```
+
+## Heartbeat
+For long running jobs that may run for an unpredictable amounts of time, you may send periodic heartbeats to reset the expiration time and allow the job to run for longer (if the job stops sending heartbeats and the expiration date run out, the job will be assumed lost and recovered). Example:
+
+```ruby
+class LongRunningWorker
+ include Sidekiq::Worker
+ include AtomicSidekiq::Heartbeat
+
+ def perform
+ (1..10_000).each do
+ ExampleClass.long_running_action!
+ heartbeat! # You can also give a specific timeout period, e.g. heartbeat!(1.hour)
+ end
+ end
end
```
## Benchmark
### Reliability