sidekiq-unique-jobs 6.0.0.rc1 → 6.0.0.rc2
Sign up to get free protection for your applications and to get access to all the features.
Potentially problematic release.
This version of sidekiq-unique-jobs might be problematic. Click here for more details.
- checksums.yaml +4 -4
- data/CHANGELOG.md +1 -0
- data/README.md +0 -19
- data/lib/sidekiq_unique_jobs/version.rb +1 -1
- data/redis/delete.lua +3 -2
- data/redis/release_lock.lua +1 -1
- metadata +1 -1
checksums.yaml
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
---
|
|
2
2
|
SHA256:
|
|
3
|
-
metadata.gz:
|
|
4
|
-
data.tar.gz:
|
|
3
|
+
metadata.gz: 8ee36e00cd0663929ce027ef233084358ec02d6ab4dc26146fa716e22eab22ed
|
|
4
|
+
data.tar.gz: 05abdd365d0655d1df25a80c54d4530f62fb049a4c10bbe1c39a6e855902f8a2
|
|
5
5
|
SHA512:
|
|
6
|
-
metadata.gz:
|
|
7
|
-
data.tar.gz:
|
|
6
|
+
metadata.gz: ad6188cf8bdba50eee4e1c4fbb71c64e937e9452c5f4f4dabfebe141fadc53c28e63241d5cc1f6e45fa6d10aadedc735ce4d48a0ccec94e8c6609609bd7d3bb7
|
|
7
|
+
data.tar.gz: 464b147ec401b9d85f842ef4243d60a54b1e254a6a14487534be6a81d1e9d05ef399b2f42ea9721035eadd92c27b19ecfc61ce4df2f37277cec6f3fb7cb0dfc5
|
data/CHANGELOG.md
CHANGED
data/README.md
CHANGED
|
@@ -151,25 +151,6 @@ All that is required is that you specifically set the sidekiq option for *unique
|
|
|
151
151
|
sidekiq_options unique: :while_executing
|
|
152
152
|
```
|
|
153
153
|
|
|
154
|
-
For jobs scheduled in the future it is possible to set for how long the job
|
|
155
|
-
should be unique. The job will be unique for the number of seconds configured (default 30 minutes)
|
|
156
|
-
or until the job has been completed. Thus, the job will be unique for the shorter of the two. Note that Sidekiq versions before 3.0 will remove job keys after an hour, which means jobs can remain unique for at most an hour.
|
|
157
|
-
|
|
158
|
-
If you want the unique job to stick around even after it has been successfully
|
|
159
|
-
processed then just set `unique: :until_expired`.
|
|
160
|
-
|
|
161
|
-
You can also control the `lock_expiration` of the uniqueness check. If you want to enforce uniqueness over a longer period than the default of 30 minutes then you can pass the number of seconds you want to use to the sidekiq options:
|
|
162
|
-
|
|
163
|
-
```ruby
|
|
164
|
-
sidekiq_options unique: :until_expired, lock_expiration: 120 * 60 # 2 hours
|
|
165
|
-
```
|
|
166
|
-
|
|
167
|
-
For locking modes (`:while_executing` and `:until_and_while_executing`) you can control the expiration length of the runtime uniqueness. If you want to enforce uniqueness over a longer period than the default of 60 seconds, then you can pass the number of seconds you want to use to the sidekiq options:
|
|
168
|
-
|
|
169
|
-
```ruby
|
|
170
|
-
sidekiq_options unique: :while_executing, lock_expiration: 2 * 60 # 2 minutes
|
|
171
|
-
```
|
|
172
|
-
|
|
173
154
|
Requiring the gem in your gemfile should be sufficient to enable unique jobs.
|
|
174
155
|
|
|
175
156
|
### Finer Control over Uniqueness
|
data/redis/delete.lua
CHANGED
|
@@ -2,10 +2,11 @@ local exists_key = KEYS[1]
|
|
|
2
2
|
local grabbed_key = KEYS[2]
|
|
3
3
|
local available_key = KEYS[3]
|
|
4
4
|
local version_key = KEYS[4]
|
|
5
|
-
local unique_digest = KEYS[5]
|
|
5
|
+
local unique_digest = KEYS[5] -- TODO: Legacy support (Remove in v6.1)
|
|
6
6
|
|
|
7
7
|
redis.call('DEL', exists_key)
|
|
8
8
|
redis.call('DEL', grabbed_key)
|
|
9
9
|
redis.call('DEL', available_key)
|
|
10
10
|
redis.call('DEL', version_key)
|
|
11
|
-
redis.call('DEL',
|
|
11
|
+
redis.call('DEL', 'uniquejobs') -- TODO: Old job hash, just drop the darn thing
|
|
12
|
+
redis.call('DEL', unique_digest) -- TODO: Legacy support (Remove in v6.1)
|
data/redis/release_lock.lua
CHANGED
|
@@ -5,7 +5,7 @@ local stored_jid = redis.pcall('get', unique_key)
|
|
|
5
5
|
if stored_jid then
|
|
6
6
|
if stored_jid == job_id or stored_jid == '2' then
|
|
7
7
|
redis.pcall('del', unique_key)
|
|
8
|
-
redis.pcall('
|
|
8
|
+
redis.pcall('HDEL', 'uniquejobs', job_id)
|
|
9
9
|
return 1
|
|
10
10
|
else
|
|
11
11
|
return 0
|