que-locks 0.2.0 → 0.3.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: bd840db1d95e1dc04b8efae206dfd9600423999972af509b37266187d53dd535
-  data.tar.gz: 3505096ad35333c9b2fb00397e8c3ba5266097f8d180e9a0fb76d5ba9b12e16a
+  metadata.gz: 809491912a7146d6ac1d4df762d88efb1e4bc9a1ae037769b937275fea35b502
+  data.tar.gz: b562eb878454d0a03939cbbcd3b81371478c7f36aea12c428a568da6ea23dc19
 SHA512:
-  metadata.gz: 9aaee5425dc4819614715e3364f608d03bb2985b1a05420acb0fcc7ef500a63398ddfa19137dc6762a9747346cd72bb27747b27cfaa729fc2f56b93e4d833e3f
-  data.tar.gz: adb3ad01415719ad0845ff3141f3e102a2edde81b2ff9fa68cfe3fac68d41c6c6fdebf76e447e3112a9639c57244baa5f48938903dc1b7c3b8b0405862458935
+  metadata.gz: 12a5d34c46c3eadd293885796eedc264b77c751cc5f31ec063e75a6a878f5ec7bec42c1716e51798db3006fa6be44419129e9421da1d012cd8aa1432e668fbb7
+  data.tar.gz: 63185315f4926d0d2226c0231e207c9c4417c443f56deac59dd771711a64c142cb1906cce1a8b898b8bc31902279d8f5cc34d4d213b592f5993f1ebc46d44ba7

data/.rubocop.yml

@@ -4,6 +4,8 @@ AllCops:
     - "node_modules/**/*"
     - "test/scratch/**/*"
   TargetRubyVersion: 2.6
+  NewCops: disable
+  SuggestExtensions: false
 
 require:
   - rubocop-performance
@@ -31,3 +33,6 @@ Lint/AmbiguousBlockAssociation:
 
 Bundler/OrderedGems:
   Enabled: false
+
+Gemspec/RequiredRubyVersion:
+  Enabled: false

data/.ruby-gemset

@@ -0,0 +1 @@
+que-locks

data/.ruby-version

@@ -0,0 +1 @@
+2.6.4

data/Gemfile

@@ -1,22 +1,21 @@
 source "https://rubygems.org"
 
-git_source(:github) {|repo_name| "https://github.com/#{repo_name}" }
-
-gem 'que', '1.0.0.beta3', github: 'chanks/que'
+git_source(:github) { |repo_name| "https://github.com/#{repo_name}" }
 
 # Specify your gem's dependencies in que-locks.gemspec
 gemspec
 
 group :development do
-  gem 'activerecord'
-  gem 'pg'
-  gem 'database_cleaner'
+  gem "activerecord"
+  gem "activejob"
+  gem "pg"
+  gem "database_cleaner"
 
-  gem 'minitest'
+  gem "minitest"
+  gem "mocha"
 
-  gem 'byebug'
-  gem 'rufo'
-  gem 'rubocop'
-  gem 'rubocop-performance'
+  gem "byebug"
+  gem "rufo"
+  gem "rubocop"
+  gem "rubocop-performance"
 end
-

data/Gemfile.lock

@@ -1,75 +1,89 @@
-GIT
-  remote: https://github.com/chanks/que
-  revision: 53106609b24d7e8bc231ae3883f69dca8c989d9d
-  specs:
-    que (1.0.0.beta3)
-
 PATH
   remote: .
   specs:
-    que-locks (0.2.0)
-      neatjson
-      que (~> 1.0.0.beta3)
-      xxhash
+    que-locks (0.3.0)
+      neatjson (~> 0.9)
+      que (~> 1.0)
+      xxhash (~> 0.4)
 
 GEM
   remote: https://rubygems.org/
   specs:
-    activemodel (6.0.1)
-      activesupport (= 6.0.1)
-    activerecord (6.0.1)
-      activemodel (= 6.0.1)
-      activesupport (= 6.0.1)
-    activesupport (6.0.1)
+    activejob (6.1.6.1)
+      activesupport (= 6.1.6.1)
+      globalid (>= 0.3.6)
+    activemodel (6.1.6.1)
+      activesupport (= 6.1.6.1)
+    activerecord (6.1.6.1)
+      activemodel (= 6.1.6.1)
+      activesupport (= 6.1.6.1)
+    activesupport (6.1.6.1)
       concurrent-ruby (~> 1.0, >= 1.0.2)
-      i18n (>= 0.7, < 2)
-      minitest (~> 5.1)
-      tzinfo (~> 1.1)
-      zeitwerk (~> 2.2)
-    ast (2.4.0)
-    byebug (11.0.1)
-    concurrent-ruby (1.1.5)
-    database_cleaner (1.7.0)
-    i18n (1.7.0)
+      i18n (>= 1.6, < 2)
+      minitest (>= 5.1)
+      tzinfo (~> 2.0)
+      zeitwerk (~> 2.3)
+    ast (2.4.2)
+    byebug (11.1.3)
+    concurrent-ruby (1.1.10)
+    database_cleaner (2.0.1)
+      database_cleaner-active_record (~> 2.0.0)
+    database_cleaner-active_record (2.0.1)
+      activerecord (>= 5.a)
+      database_cleaner-core (~> 2.0.0)
+    database_cleaner-core (2.0.1)
+    globalid (1.0.0)
+      activesupport (>= 5.0)
+    i18n (1.12.0)
       concurrent-ruby (~> 1.0)
-    jaro_winkler (1.5.4)
-    minitest (5.13.0)
+    json (2.6.2)
+    minitest (5.16.2)
+    mocha (1.14.0)
     neatjson (0.9)
-    parallel (1.19.1)
-    parser (2.6.5.0)
-      ast (~> 2.4.0)
-    pg (1.1.4)
-    rainbow (3.0.0)
+    parallel (1.22.1)
+    parser (3.1.2.0)
+      ast (~> 2.4.1)
+    pg (1.4.2)
+    que (1.4.1)
+    rainbow (3.1.1)
     rake (10.5.0)
-    rubocop (0.76.0)
-      jaro_winkler (~> 1.5.1)
+    regexp_parser (2.5.0)
+    rexml (3.2.5)
+    rubocop (1.32.0)
+      json (~> 2.3)
       parallel (~> 1.10)
-      parser (>= 2.6)
+      parser (>= 3.1.0.0)
       rainbow (>= 2.2.2, < 4.0)
+      regexp_parser (>= 1.8, < 3.0)
+      rexml (>= 3.2.5, < 4.0)
+      rubocop-ast (>= 1.19.1, < 2.0)
       ruby-progressbar (~> 1.7)
-      unicode-display_width (>= 1.4.0, < 1.7)
-    rubocop-performance (1.5.1)
-      rubocop (>= 0.71.0)
-    ruby-progressbar (1.10.1)
-    rufo (0.7.0)
-    thread_safe (0.3.6)
-    tzinfo (1.2.5)
-      thread_safe (~> 0.1)
-    unicode-display_width (1.6.0)
-    xxhash (0.4.0)
-    zeitwerk (2.2.1)
+      unicode-display_width (>= 1.4.0, < 3.0)
+    rubocop-ast (1.19.1)
+      parser (>= 3.1.1.0)
+    rubocop-performance (1.14.3)
+      rubocop (>= 1.7.0, < 2.0)
+      rubocop-ast (>= 0.4.0)
+    ruby-progressbar (1.11.0)
+    rufo (0.13.0)
+    tzinfo (2.0.5)
+      concurrent-ruby (~> 1.0)
+    unicode-display_width (2.2.0)
+    xxhash (0.5.0)
+    zeitwerk (2.6.0)
 
 PLATFORMS
   ruby
 
 DEPENDENCIES
+  activejob
   activerecord
-  bundler (~> 1.17)
+  bundler (~> 2.0)
   byebug
   database_cleaner
   minitest
+  mocha
   pg
-  que (= 1.0.0.beta3)!
   que-locks!
   rake (~> 10.0)
   rubocop
@@ -77,4 +91,4 @@ DEPENDENCIES
   rufo
 
 BUNDLED WITH
-   1.17.2
+   2.3.18

data/README.md

@@ -1,10 +1,10 @@
-# Que::Locks
+# Que::Locks ![Ruby](https://github.com/airhorns/que-locks/workflows/Ruby/badge.svg)
 
-`que-locks` adds an opt-in feature to `Que::Jobs` allowing jobs to specify that exactly one instance of a job should be executing at once. This is useful for jobs that are doing something important that should only ever happen one at a time, like processing a payment for a given user, or super expensive jobs that could cause thundering herd problems if enqueued all at the same time.
+`que-locks` adds an opt-in exclusive execution lock to [Que](https://github.com/que-rb/que), a robust and simple Postgres based background job library. Jobs can specify that exactly one instance of a job should be executing at once and `que-locks` will prevent the enqueuing and execution of any other instance of the same job with the same arguments. This is useful for jobs that are doing something important that should only ever happen one at a time, like processing a payment for a given user, or super expensive jobs that could cause thundering herd problems if enqueued all at the same time.
 
-`que-locks` uses Postgres' advisory locks in a similar manner as que `0.x` did to provide scalable and automatically cleaned up locking around job execution. `que-locks` provides slightly better atomicity guarantees compared to the locking functionality of Redis based job queues for the same reasons `que` can as well. Because locks are taken and released using the same database connection that the `que` worker uses to pull jobs, the transactional semantics apply just the same where locks are automatically released if the connection fails, unlike the multistep Redis logic that requires complicated crash cleanup.
+`que-locks` uses Postgres' advisory locks in a similar manner as que does to provide scalable and automatically cleaned-up-locking around job execution. `que-locks` provides slightly better atomicity guarantees compared to the locking functionality of Redis based job queues for the same reasons `que` can as well! Because locks are taken and released using the same database connection that the `que` worker uses to pull jobs, the robust transactional semantics Postgres provides apply just the same. Locks are automatically released if the connection fails, and don't require heart-beating beyond what the Postgres client already does, unlike the multi-step Redis logic that requires lock TTLs, heartbeats, and complicated crash cleanup.
 
-This is also sometimes called "unique jobs", "job concurrency limiting", and "exclusive jobs".
+This is also sometimes called _unique jobs_, _serialized jobs_, _job concurrency limiting_, and/or _exclusive jobs_.
 
 ## Installation
 
@@ -16,11 +16,15 @@ gem 'que-locks'
 
 And then execute:
 
-    $ bundle
+```
+$ bundle
+```
 
 Or install it yourself as:
 
-    $ gem install que-locks
+```
+$ gem install que-locks
+```
 
 ## Usage
 
@@ -38,43 +42,69 @@ end
 
 That's it!
 
-#### Checking lock status
+## Configuration (Important!)
+
+Right now, `que-locks` does __not__ support Que running with a `--worker-count` greater than 1! This is because the locking strategy is not compatible with the way Que uses its connection pool. This is a big limitation we hope to remove, but please note that you must run Que with one worker per process when using `que-locks`.
+
+### Checking lock status
 
 Occasionally, code enqueuing a job might want to check if the job is already running and do something different if it is, like display a message to the user or log the skipped execution. `que-locks` supports some basic job lock introspection like so:
 
 ```ruby
-SomeJobClass.exclusive_execution_lock  #=> returns true if the job is indeed using que-locks
+SomeJob.exclusive_execution_lock  #=> returns true if the job is indeed using que-locks
 
-SomeJobClass.lock_available?(user_id: 1)  #=> returns true if no job is currently enqueued with these arguments or running right now holding the lock
+SomeJob.lock_available?(user_id: 1)  #=> returns true if no job is currently enqueued with these arguments or running right now holding the lock
 ```
 
-Note that checking the lock's availability reports on the current state of the locks, but that state might change in between when the check is made and if/when the job is enqueued with the same arguments. Put differently, the `#lock_available?` method is advisory to user code, and doesn't actaully reserve the lock or execute a compare-and-swap operation. It's safe for multiple processes to race to enqueue a job after checking to see that the lock is available, as only one will still be executed, but they may both report that the lock was available before enqueuing.
+**Note**: Checking the lock's availability reports on the current state of the locks, but that state might change in between when the check is made and if/when the job is enqueued with the same arguments. Put differently, the `#lock_available?` method is advisory to user code, and doesn't actually reserve the lock or execute a compare-and-swap operation. It's safe for multiple processes to race to enqueue a job after checking to see that the lock is available, as only one will still be executed, but they may both report that the lock was available before enqueuing.
 
 ## Semantics
 
-`que-locks` guarantees that the maximum number of instances given job class executing with a given set of arguments will be one. This means that:
+`que-locks` guarantees that the maximum number of instances of a given job class executing with a given set of arguments will be one. This means that:
 
+- two of the same job class each pushed with the same arguments may result in one or two executions, but they won't ever be simultaneous
 - two of the same job class each pushed with different arguments can both execute simultaneously
 - if the job takes no arguments, there can only ever be one executing globally
-- two of the same job class each pushed with the same arguments may result in one or two executions, but they won't ever be simultaneous
 
-In some instances, multiple jobs with the same arguments can be enqueued and sit in the queue simultaneously. Despite this the semantics above will remain in tact: only one job will execute at once. The first one worked will get the lock and the second one worked will skip execution if the first job is still executing. `que-locks` tries to avoid extraneous job pushes by checking to see if the lock for a job is available at enqueue time, and skipping enqueue if so. This preemptive lock check helps keeps queues small in the event that a huge number of identical jobs are pushed at once.
+In some instances, multiple jobs with the same class and arguments can be enqueued and sit in the queue simultaneously. Despite this, the semantics above will remain in tact: only one job will execute at once. The first one dequeued will get the lock, and the second one dequeued will skip execution if the first job is still executing when it checks. If 100 of the same job class are enqueued all at the same time with the same arguments, only one will run simultaneously, but that more than one might run by the time the queue is empty.
 
 `que-locks` uses a sorted JSON serialized version of the arguments to compute lock keys, so it's important that arguments that should be considered identical JSON serialize using `Que.serialize_json` to the exact same string.
 
 `que-locks` adds no overhead to jobs that don't use locking, adds one more SQL query to check an advisory lock (which is only memory access) to enqueuing jobs, and adds two more SQL queries to lock and unlock to job execution.
 
+### Preemptive lock checking (dropped enqueues)
+
+`que-locks` tries to avoid extraneous job pushes by checking to see if the lock for a job is available at enqueue time, and skipping enqueue for the job if so. This means that if you enqueue 100 jobs all at once, likely very few will end up executing total because the first job executed will take out the lock and the preemptive enqueue check for the jobs yet to be enqueued will start failing. This preemptive lock check helps keeps queues small in the event that a huge number of identical jobs are pushed at once. It is worth noting that this job dropping behaviour happens already at dequeue time as well if the lock is already out, and this is just doing the check earlier in the process to enqueue fewer jobs.
+
+In some instances this may be undesirable if the job must absolutely run. In this instance, we suggest not using an execution lock, but, you may still want control over how many are running at once. One alternative is pushing some kind of idempotency token or further identifier as one of the job's arguments to change the lock key such that the dropped jobs are ok to drop.
+
+Otherwise, we suggest throttling the concurrency of a given `que` queue name by controlling the number of que workers working it, and enqueuing the jobs that must not run simultaneously to that queue name.
+
+```ruby
+class ProcessCreditCardJob < Que::Job
+  self.queue = 'remote_api_jobs'
+end
+
+# and then run que against that queue with a limited worker count to take it easy on the remote API
+# que --queue-name remote_api_jobs --worker-count 2
+```
+
+See https://github.com/que-rb/que/tree/master/docs#multiple-queues for more information on setting concurrency for multiple queue names.
+
+It can be tricky to puzzle out if you have a job locking or a job concurrency limiting problem. A good rule of thumb to identify a locking problem is to ask if the jobs are idempotent or redundant if simultaneously executed. If they are, and it is indeed ok to drop jobs from existence if they happen to run at the same time as a clone is running, it's a locking problem that optimizes from doing redundant work. If all jobs must be run, even if they take the exact same arguments, but they maybe just need to be serialized such that only one runs at once, a concurrency limiting approach applies better.
+
 ## Missing features
 
 - Configurable preemptive lock checking at enqueue time
 - Selective argument comparison for lock key computation
 - maybe a `que-web` integration to expose lock info
+- ActiveJob integration for Rails users. It'd be nice for those who prefer the ActiveJob::Job API to use `que-locks` for nice transactional locking semantics, but this doesn't exist yet. In the meantime, we suggest using `Que::Job` directly.
 
 If you wish for any of this stuff, feel free to open a PR, contributions are always welcome!!
 
 ## Non features
 
-- Locking to a limited concurrency greater than 1. If you want a lock that several different jobs can take out, a good option is to use Que's multiple queue support and run a limited number of workers working a certain queue so the concurrency is limited by the available worker slots.
+- Locking to a limited concurrency greater than 1. Also called semaphore tickets. If you want a lock that several different jobs can take out, a good option is to use Que's multiple queue support and run a limited number of workers working a certain queue so the concurrency is limited by the available worker slots. This is absent because it adds a lot of complexity to the locking code as Postgres doesn't natively support these cross-session, stacking advisory locks.
 
 ## Development
 
@@ -84,7 +114,7 @@ To install this gem onto your local machine, run `bundle exec rake install`. To
 
 ## Contributing
 
-Bug reports and pull requests are welcome on GitHub at https://github.com/hornairs/que-locks. This project is intended to be a safe, welcoming space for collaboration, and contributors are expected to adhere to the [Contributor Covenant](http://contributor-covenant.org) code of conduct.
+Bug reports and pull requests are welcome on GitHub at https://github.com/airhorns/que-locks. This project is intended to be a safe, welcoming space for collaboration, and contributors are expected to adhere to the [Contributor Covenant](http://contributor-covenant.org) code of conduct.
 
 ## License
 
@@ -93,7 +123,3 @@ The gem is available as open source under the terms of the [MIT License](https:/
 ## Code of Conduct
 
 Everyone interacting in the Que::Locks project’s codebases, issue trackers, chat rooms and mailing lists is expected to follow the [code of conduct](https://github.com/hornairs/que-locks/blob/master/CODE_OF_CONDUCT.md).
-
-```
-
-```

data/docker-compose.yml

@@ -0,0 +1,12 @@
+version: '3.2'
+
+services:
+  postgres:
+    image: postgres:12
+    ports:
+      - 5432:5432
+    restart: on-failure
+    environment:
+      POSTGRES_USER: que_locks
+      POSTGRES_DB: que_locks_test
+      POSTGRES_HOST_AUTH_METHOD: trust # don't require password

data/lib/que/locks/job_extensions.rb

@@ -2,25 +2,34 @@ module Que::Locks
   module JobExtensions
     attr_accessor :exclusive_execution_lock
 
-    def lock_available?(*args, queue: nil, priority: nil, run_at: nil, job_class: nil, tags: nil, **arg_opts) # rubocop:disable Lint/UnusedMethodArgument
-      args << arg_opts if arg_opts.any?
+    def lock_available?(*args, queue: nil, priority: nil, run_at: nil, job_class: nil, tags: nil, job_options: {}, **kwargs) # rubocop:disable Lint/UnusedMethodArgument
+      args << kwargs if kwargs.any?
       return true unless self.exclusive_execution_lock
       return false if Que::Locks::ExecutionLock.already_enqueued_job_wanting_lock?(self, args)
       return Que::Locks::ExecutionLock.can_aquire?(self, args)
     end
 
-    def enqueue(*args, queue: nil, priority: nil, run_at: nil, job_class: nil, tags: nil, **arg_opts)
+    def enqueue(*args, queue: nil, priority: nil, run_at: nil, job_class: nil, tags: nil, job_options: {}, **kwargs)
+      forwardable_kwargs = kwargs.clone
+      forwardable_kwargs[:job_options] = {
+        queue: queue,
+        priority: priority,
+        run_at: run_at,
+        job_class: job_class,
+        tags: tags,
+      }.merge(job_options)
+
       if self.exclusive_execution_lock
         args_list = args.clone
-        args_list << arg_opts if arg_opts.any?
+        args_list << kwargs if kwargs.any?
 
         if Que::Locks::ExecutionLock.already_enqueued_job_wanting_lock?(self, args_list)
           Que.log(level: :info, event: :skipped_enqueue_due_to_preemptive_lock_check, args: args_list)
         else
-          super
+          super(*args, **forwardable_kwargs)
         end
       else
-        super
+        super(*args, **forwardable_kwargs)
       end
     end
   end

data/lib/que/locks/version.rb

@@ -1,5 +1,5 @@
 module Que
   module Locks
-    VERSION = "0.2.0"
+    VERSION = "0.3.0".freeze
   end
 end

data/que-locks.gemspec

@@ -1,4 +1,3 @@
-
 lib = File.expand_path("../lib", __FILE__)
 $LOAD_PATH.unshift(lib) unless $LOAD_PATH.include?(lib)
 require "que/locks/version"
@@ -22,10 +21,10 @@ Gem::Specification.new do |spec|
   spec.executables = spec.files.grep(%r{^exe/}) { |f| File.basename(f) }
   spec.require_paths = ["lib"]
 
-  spec.add_development_dependency "bundler", "~> 1.17"
+  spec.add_development_dependency "bundler", '~> 2.0'
   spec.add_development_dependency "rake", "~> 10.0"
 
-  spec.add_dependency "neatjson"
-  spec.add_dependency "que", "~> 1.0.0.beta3"
-  spec.add_dependency "xxhash"
+  spec.add_dependency "neatjson", '~> 0.9'
+  spec.add_dependency "que", "~> 1.0"
+  spec.add_dependency "xxhash", '~> 0.4'
 end

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: que-locks
 version: !ruby/object:Gem::Version
-  version: 0.2.0
+  version: 0.3.0
 platform: ruby
 authors:
 - Harry Brundage
 autorequire: 
 bindir: exe
 cert_chain: []
-date: 2019-11-28 00:00:00.000000000 Z
+date: 2022-07-29 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: bundler
@@ -16,14 +16,14 @@ dependencies:
     requirements:
     - - "~>"
       - !ruby/object:Gem::Version
-        version: '1.17'
+        version: '2.0'
   type: :development
   prerelease: false
   version_requirements: !ruby/object:Gem::Requirement
     requirements:
     - - "~>"
       - !ruby/object:Gem::Version
-        version: '1.17'
+        version: '2.0'
 - !ruby/object:Gem::Dependency
   name: rake
   requirement: !ruby/object:Gem::Requirement
@@ -42,44 +42,44 @@ dependencies:
   name: neatjson
   requirement: !ruby/object:Gem::Requirement
     requirements:
-    - - ">="
+    - - "~>"
       - !ruby/object:Gem::Version
-        version: '0'
+        version: '0.9'
   type: :runtime
   prerelease: false
   version_requirements: !ruby/object:Gem::Requirement
     requirements:
-    - - ">="
+    - - "~>"
       - !ruby/object:Gem::Version
-        version: '0'
+        version: '0.9'
 - !ruby/object:Gem::Dependency
   name: que
   requirement: !ruby/object:Gem::Requirement
     requirements:
     - - "~>"
       - !ruby/object:Gem::Version
-        version: 1.0.0.beta3
+        version: '1.0'
   type: :runtime
   prerelease: false
   version_requirements: !ruby/object:Gem::Requirement
     requirements:
     - - "~>"
       - !ruby/object:Gem::Version
-        version: 1.0.0.beta3
+        version: '1.0'
 - !ruby/object:Gem::Dependency
   name: xxhash
   requirement: !ruby/object:Gem::Requirement
     requirements:
-    - - ">="
+    - - "~>"
       - !ruby/object:Gem::Version
-        version: '0'
+        version: '0.4'
   type: :runtime
   prerelease: false
   version_requirements: !ruby/object:Gem::Requirement
     requirements:
-    - - ">="
+    - - "~>"
       - !ruby/object:Gem::Version
-        version: '0'
+        version: '0.4'
 description: 
 email:
 - harry.brundage@gmail.com
@@ -89,6 +89,8 @@ extra_rdoc_files: []
 files:
 - ".gitignore"
 - ".rubocop.yml"
+- ".ruby-gemset"
+- ".ruby-version"
 - CODE_OF_CONDUCT.md
 - Gemfile
 - Gemfile.lock
@@ -99,6 +101,7 @@ files:
 - bin/lint
 - bin/lintfix
 - bin/setup
+- docker-compose.yml
 - lib/que/locks.rb
 - lib/que/locks/execution_lock.rb
 - lib/que/locks/job_extensions.rb
@@ -125,7 +128,7 @@ required_rubygems_version: !ruby/object:Gem::Requirement
     - !ruby/object:Gem::Version
       version: '0'
 requirements: []
-rubygems_version: 3.0.3
+rubygems_version: 3.0.6
 signing_key: 
 specification_version: 4
 summary: Job locking for que jobs such that only one can be in the queue or executing