solid_queue 0.1.1 → 0.1.2
Sign up to get free protection for your applications and to get access to all the features.
- checksums.yaml +4 -4
- data/README.md +69 -38
- data/app/models/solid_queue/blocked_execution.rb +1 -1
- data/app/models/solid_queue/claimed_execution.rb +0 -5
- data/app/models/solid_queue/process/prunable.rb +1 -1
- data/app/models/solid_queue/ready_execution.rb +1 -1
- data/app/models/solid_queue/record.rb +3 -3
- data/app/models/solid_queue/scheduled_execution.rb +1 -1
- data/db/migrate/20231211200639_create_solid_queue_tables.rb +1 -1
- data/lib/generators/solid_queue/install/install_generator.rb +4 -0
- data/lib/generators/solid_queue/install/templates/config.yml +18 -0
- data/lib/solid_queue/configuration.rb +22 -14
- data/lib/solid_queue/supervisor.rb +2 -2
- data/lib/solid_queue/version.rb +1 -1
- metadata +3 -2
checksums.yaml
CHANGED
@@ -1,7 +1,7 @@
|
|
1
1
|
---
|
2
2
|
SHA256:
|
3
|
-
metadata.gz:
|
4
|
-
data.tar.gz:
|
3
|
+
metadata.gz: 2e1ff04f60a3eee3be19e692691ef7a70cd1cfc1a2edd5f019f6bbab9b8614e6
|
4
|
+
data.tar.gz: bc96a464a966379d434b4e8c45c4ad24c30bf3aeed6d3b6acc60d94e1386a14e
|
5
5
|
SHA512:
|
6
|
-
metadata.gz:
|
7
|
-
data.tar.gz:
|
6
|
+
metadata.gz: 27d7bf13f3342cfccd54aa3cc3db18284d68b7fc56ae62b2c9ca66710aadb0eb8e37c48b8b268169fa37aac523cbe1cdb2dd7146fd160499d82e4521cb35d2ba
|
7
|
+
data.tar.gz: df8f520b23ab98bdcea47ffab06df3bfa1e946072070d251ecd0d5e44a6f7e723fdd6278344b4dbf88a8d184ce661f97440ba188267d004df83a5df66945bedc
|
data/README.md
CHANGED
@@ -2,6 +2,8 @@
|
|
2
2
|
|
3
3
|
Solid Queue is a DB-based queuing backend for [Active Job](https://edgeguides.rubyonrails.org/active_job_basics.html), designed with simplicity and performance in mind.
|
4
4
|
|
5
|
+
Besides regular job enqueuing and processing, Solid Queue supports delayed jobs, concurrency controls, pausing queues, numeric priorities per job, and priorities by queue order. _Proper support for `perform_all_later`, improvements to logging and instrumentation, a better CLI tool, a way to run within an existing process in "async" mode, unique jobs and recurring, cron-like tasks are coming very soon._
|
6
|
+
|
5
7
|
Solid Queue can be used with SQL databases such as MySQL, PostgreSQL or SQLite, and it leverages the `FOR UPDATE SKIP LOCKED` clause, if available, to avoid blocking and waiting on locks when polling jobs. It relies on Active Job for retries, discarding, error handling, serialization, or delays, and it's compatible with Ruby on Rails multi-threading.
|
6
8
|
|
7
9
|
## Usage
|
@@ -39,14 +41,24 @@ Or install it yourself as:
|
|
39
41
|
$ gem install solid_queue
|
40
42
|
```
|
41
43
|
|
42
|
-
|
44
|
+
Install Migrations and Set Up Active Job Adapter
|
45
|
+
Now, you need to install the necessary migrations and configure the Active Job's adapter. Run the following commands:
|
46
|
+
```bash
|
47
|
+
$ bin/rails generate solid_queue:install
|
43
48
|
```
|
49
|
+
|
50
|
+
or add the only the migration to your app and run it:
|
51
|
+
```bash
|
44
52
|
$ bin/rails solid_queue:install:migrations
|
53
|
+
```
|
54
|
+
|
55
|
+
Run the Migrations (required after either of the above steps):
|
56
|
+
```bash
|
45
57
|
$ bin/rails db:migrate
|
46
58
|
```
|
47
59
|
|
48
60
|
With this, you'll be ready to enqueue jobs using Solid Queue, but you need to start Solid Queue's supervisor to run them.
|
49
|
-
```
|
61
|
+
```bash
|
50
62
|
$ bundle exec rake solid_queue:start
|
51
63
|
```
|
52
64
|
|
@@ -61,7 +73,7 @@ Besides Rails 7, Solid Queue works best with MySQL 8+ or PostgreSQL 9.5+, as the
|
|
61
73
|
|
62
74
|
We have three types of processes in Solid Queue:
|
63
75
|
- _Workers_ are in charge of picking jobs ready to run from queues and processing them. They work off the `solid_queue_ready_executions` table.
|
64
|
-
- _Dispatchers_ are in charge of selecting jobs scheduled to run in the future that are due and _dispatching_ them, which is simply moving them from the `
|
76
|
+
- _Dispatchers_ are in charge of selecting jobs scheduled to run in the future that are due and _dispatching_ them, which is simply moving them from the `solid_queue_scheduled_executions` table over to the `solid_queue_ready_executions` table so that workers can pick them up. They also do some maintenance work related to concurrency controls.
|
65
77
|
- The _supervisor_ forks workers and dispatchers according to the configuration, controls their heartbeats, and sends them signals to stop and start them when needed.
|
66
78
|
|
67
79
|
By default, Solid Queue will try to find your configuration under `config/solid_queue.yml`, but you can set a different path using the environment variable `SOLID_QUEUE_CONFIG`. This is what this configuration looks like:
|
@@ -72,10 +84,10 @@ production:
|
|
72
84
|
- polling_interval: 1
|
73
85
|
batch_size: 500
|
74
86
|
workers:
|
75
|
-
- queues: *
|
87
|
+
- queues: "*"
|
76
88
|
threads: 3
|
77
89
|
polling_interval: 2
|
78
|
-
- queues: real_time,background
|
90
|
+
- queues: [ real_time, background ]
|
79
91
|
threads: 5
|
80
92
|
polling_interval: 0.1
|
81
93
|
processes: 3
|
@@ -83,20 +95,22 @@ production:
|
|
83
95
|
|
84
96
|
Everything is optional. If no configuration is provided, Solid Queue will run with one dispatcher and one worker with default settings.
|
85
97
|
|
86
|
-
- `polling_interval`: the time interval in seconds that workers and dispatchers will wait before checking for more jobs. This time defaults to `
|
87
|
-
- `batch_size`: the dispatcher will dispatch jobs in batches of this size.
|
88
|
-
- `queues`: the list of queues that workers will pick jobs from. You can use `*` to indicate all queues (which is also the default and the behaviour you'll get if you omit this). You can provide a
|
89
|
-
```yml
|
90
|
-
staging:
|
91
|
-
workers:
|
92
|
-
- queues: staging*
|
93
|
-
threads: 3
|
94
|
-
polling_interval: 5
|
98
|
+
- `polling_interval`: the time interval in seconds that workers and dispatchers will wait before checking for more jobs. This time defaults to `1` second for dispatchers and `0.1` seconds for workers.
|
99
|
+
- `batch_size`: the dispatcher will dispatch jobs in batches of this size. The default is 500.
|
100
|
+
- `queues`: the list of queues that workers will pick jobs from. You can use `*` to indicate all queues (which is also the default and the behaviour you'll get if you omit this). You can provide a single queue, or a list of queues as an array. Jobs will be polled from those queues in order, so for example, with `[ real_time, background ]`, no jobs will be taken from `background` unless there aren't any more jobs waiting in `real_time`. You can also provide a prefix with a wildcard to match queues starting with a prefix. For example:
|
95
101
|
|
96
|
-
```
|
97
|
-
|
102
|
+
```yml
|
103
|
+
staging:
|
104
|
+
workers:
|
105
|
+
- queues: staging*
|
106
|
+
threads: 3
|
107
|
+
polling_interval: 5
|
98
108
|
|
99
|
-
|
109
|
+
```
|
110
|
+
|
111
|
+
This will create a worker fetching jobs from all queues starting with `staging`. The wildcard `*` is only allowed on its own or at the end of a queue name; you can't specify queue names such as `*_some_queue`. These will be ignored.
|
112
|
+
|
113
|
+
Finally, you can combine prefixes with exact names, like `[ staging*, background ]`, and the behaviour with respect to order will be the same as with only exact names.
|
100
114
|
- `threads`: this is the max size of the thread pool that each worker will have to run jobs. Each worker will fetch this number of jobs from their queue(s), at most and will post them to the thread pool to be run. By default, this is `5`. Only workers have this setting.
|
101
115
|
- `processes`: this is the number of worker processes that will be forked by the supervisor with the settings given. By default, this is `1`, just a single process. This setting is useful if you want to dedicate more than one CPU core to a queue or queues with the same configuration. Only workers have this setting.
|
102
116
|
|
@@ -129,23 +143,25 @@ There are several settings that control how Solid Queue works that you can set a
|
|
129
143
|
- `logger`: the logger you want Solid Queue to use. Defaults to the app logger.
|
130
144
|
- `app_executor`: the [Rails executor](https://guides.rubyonrails.org/threading_and_code_execution.html#executor) used to wrap asynchronous operations, defaults to the app executor
|
131
145
|
- `on_thread_error`: custom lambda/Proc to call when there's an error within a thread that takes the exception raised as argument. Defaults to
|
132
|
-
|
133
|
-
|
134
|
-
|
146
|
+
|
147
|
+
```ruby
|
148
|
+
-> (exception) { Rails.error.report(exception, handled: false) }
|
149
|
+
```
|
135
150
|
- `connects_to`: a custom database configuration that will be used in the abstract `SolidQueue::Record` Active Record model. This is required to use a different database than the main app. For example:
|
136
|
-
|
151
|
+
|
152
|
+
```ruby
|
137
153
|
# Use a separate DB for Solid Queue
|
138
154
|
config.solid_queue.connects_to = { database: { writing: :solid_queue_primary, reading: :solid_queue_replica } }
|
139
|
-
```
|
155
|
+
```
|
140
156
|
- `use_skip_locked`: whether to use `FOR UPDATE SKIP LOCKED` when performing locking reads. This will be automatically detected in the future, and for now, you'd only need to set this to `false` if your database doesn't support it. For MySQL, that'd be versions < 8, and for PostgreSQL, versions < 9.5. If you use SQLite, this has no effect, as writes are sequential.
|
141
|
-
- `process_heartbeat_interval`: the heartbeat interval that all processes will follow—defaults to
|
142
|
-
- `process_alive_threshold`: how long to wait until a process is considered dead after its last heartbeat—defaults to
|
143
|
-
- `shutdown_timeout`: time the supervisor will wait since it sent the `TERM` signal to its supervised processes before sending a `QUIT` version to them requesting immediate termination—defaults to
|
144
|
-
- `silence_polling`: whether to silence Active Record logs emitted when polling for both workers and dispatchers—defaults to
|
157
|
+
- `process_heartbeat_interval`: the heartbeat interval that all processes will follow—defaults to 60 seconds.
|
158
|
+
- `process_alive_threshold`: how long to wait until a process is considered dead after its last heartbeat—defaults to 5 minutes.
|
159
|
+
- `shutdown_timeout`: time the supervisor will wait since it sent the `TERM` signal to its supervised processes before sending a `QUIT` version to them requesting immediate termination—defaults to 5 seconds.
|
160
|
+
- `silence_polling`: whether to silence Active Record logs emitted when polling for both workers and dispatchers—defaults to `false`.
|
145
161
|
- `supervisor_pidfile`: path to a pidfile that the supervisor will create when booting to prevent running more than one supervisor in the same host, or in case you want to use it for a health check. It's `nil` by default.
|
146
|
-
- `preserve_finished_jobs`: whether to keep finished jobs in the `solid_queue_jobs` table—defaults to
|
147
|
-
- `clear_finished_jobs_after`: period to keep finished jobs around, in case `preserve_finished_jobs` is true—defaults to
|
148
|
-
- `default_concurrency_control_period`: the value to be used as the default for the `duration` parameter in [concurrency controls](#concurrency-controls). It defaults to
|
162
|
+
- `preserve_finished_jobs`: whether to keep finished jobs in the `solid_queue_jobs` table—defaults to `true`.
|
163
|
+
- `clear_finished_jobs_after`: period to keep finished jobs around, in case `preserve_finished_jobs` is true—defaults to 1 day. **Note:** Right now, there's no automatic cleanup of finished jobs. You'd need to do this by periodically invoking `SolidQueue::Job.clear_finished_in_batches`, but this will happen automatically in the near future.
|
164
|
+
- `default_concurrency_control_period`: the value to be used as the default for the `duration` parameter in [concurrency controls](#concurrency-controls). It defaults to 3 minutes.
|
149
165
|
|
150
166
|
|
151
167
|
## Concurrency controls
|
@@ -197,6 +213,20 @@ Note that the `duration` setting depends indirectly on the value for `concurrenc
|
|
197
213
|
|
198
214
|
Finally, failed jobs that are automatically or manually retried work in the same way as new jobs that get enqueued: they get in the queue for gaining the lock, and whenever they get it, they'll be run. It doesn't matter if they had gained the lock already in the past.
|
199
215
|
|
216
|
+
## Failed jobs and retries
|
217
|
+
|
218
|
+
Solid Queue doesn't include any automatic retry mechanism, it [relies on Active Job for this](https://edgeguides.rubyonrails.org/active_job_basics.html#retrying-or-discarding-failed-jobs). Jobs that fail will be kept in the system, and a _failed execution_ (a record in the `solid_queue_failed_executions` table) will be created for these. The job will stay there until manually discarded or re-enqueued. You can do this in a console as:
|
219
|
+
```ruby
|
220
|
+
failed_execution = SolidQueue::FailedExecution.find(...) # Find the failed execution related to your job
|
221
|
+
failed_execution.error # inspect the error
|
222
|
+
|
223
|
+
failed_execution.retry # This will re-enqueue the job as if it was enqueued for the first time
|
224
|
+
failed_execution.discard # This will delete the job from the system
|
225
|
+
```
|
226
|
+
|
227
|
+
We're planning to release a dashboard called _Mission Control_, where, among other things, you'll be able to examine and retry/discard failed jobs, one by one, or in bulk.
|
228
|
+
|
229
|
+
|
200
230
|
## Puma plugin
|
201
231
|
We provide a Puma plugin if you want to run the Solid Queue's supervisor together with Puma and have Puma monitor and manage it. You just need to add
|
202
232
|
```ruby
|
@@ -211,20 +241,21 @@ to your `puma.rb` configuration.
|
|
211
241
|
If you prefer not to rely on this, or avoid relying on it unintentionally, you should make sure that:
|
212
242
|
- Your jobs relying on specific records are always enqueued on [`after_commit` callbacks](https://guides.rubyonrails.org/active_record_callbacks.html#after-commit-and-after-rollback) or otherwise from a place where you're certain that whatever data the job will use has been committed to the database before the job is enqueued.
|
213
243
|
- Or, to opt out completely from this behaviour, configure a database for Solid Queue, even if it's the same as your app, ensuring that a different connection on the thread handling requests or running jobs for your app will be used to enqueue jobs. For example:
|
214
|
-
```ruby
|
215
|
-
class ApplicationRecord < ActiveRecord::Base
|
216
|
-
self.abstract_class = true
|
217
244
|
|
218
|
-
|
219
|
-
|
245
|
+
```ruby
|
246
|
+
class ApplicationRecord < ActiveRecord::Base
|
247
|
+
self.abstract_class = true
|
220
248
|
|
221
|
-
|
222
|
-
|
223
|
-
|
249
|
+
connects_to database: { writing: :primary, reading: :replica }
|
250
|
+
```
|
251
|
+
|
252
|
+
```ruby
|
253
|
+
config.solid_queue.connects_to = { database: { writing: :primary, reading: :replica } }
|
254
|
+
```
|
224
255
|
|
225
256
|
## Inspiration
|
226
257
|
|
227
|
-
Solid Queue has been inspired by [resque](https://github.com/resque/resque) and [GoodJob](https://github.com/bensheldon/good_job).
|
258
|
+
Solid Queue has been inspired by [resque](https://github.com/resque/resque) and [GoodJob](https://github.com/bensheldon/good_job). We recommend checking out these projects as they're great examples from which we've learnt a lot.
|
228
259
|
|
229
260
|
## License
|
230
261
|
The gem is available as open source under the terms of the [MIT License](https://opensource.org/licenses/MIT).
|
@@ -24,7 +24,7 @@ module SolidQueue
|
|
24
24
|
|
25
25
|
def release_one(concurrency_key)
|
26
26
|
transaction do
|
27
|
-
ordered.where(concurrency_key: concurrency_key).limit(1).
|
27
|
+
ordered.where(concurrency_key: concurrency_key).limit(1).non_blocking_lock.each(&:release)
|
28
28
|
end
|
29
29
|
end
|
30
30
|
|
@@ -46,7 +46,6 @@ class SolidQueue::ClaimedExecution < SolidQueue::Execution
|
|
46
46
|
|
47
47
|
private
|
48
48
|
def execute
|
49
|
-
SolidQueue.logger.info("[SolidQueue] Performing job #{job.id} - #{job.active_job_id}")
|
50
49
|
ActiveJob::Base.execute(job.arguments)
|
51
50
|
Result.new(true, nil)
|
52
51
|
rescue Exception => e
|
@@ -58,8 +57,6 @@ class SolidQueue::ClaimedExecution < SolidQueue::Execution
|
|
58
57
|
job.finished!
|
59
58
|
destroy!
|
60
59
|
end
|
61
|
-
|
62
|
-
SolidQueue.logger.info("[SolidQueue] Performed job #{job.id} - #{job.active_job_id}")
|
63
60
|
end
|
64
61
|
|
65
62
|
def failed_with(error)
|
@@ -67,7 +64,5 @@ class SolidQueue::ClaimedExecution < SolidQueue::Execution
|
|
67
64
|
job.failed_with(error)
|
68
65
|
destroy!
|
69
66
|
end
|
70
|
-
|
71
|
-
SolidQueue.logger.info("[SolidQueue] Failed job #{job.id} - #{job.active_job_id}")
|
72
67
|
end
|
73
68
|
end
|
@@ -9,7 +9,7 @@ module SolidQueue::Process::Prunable
|
|
9
9
|
|
10
10
|
class_methods do
|
11
11
|
def prune
|
12
|
-
prunable.
|
12
|
+
prunable.non_blocking_lock.find_in_batches(batch_size: 50) do |batch|
|
13
13
|
batch.each do |process|
|
14
14
|
SolidQueue.logger.info("[SolidQueue] Pruning dead process #{process.id} - #{process.metadata}")
|
15
15
|
process.deregister
|
@@ -26,7 +26,7 @@ module SolidQueue
|
|
26
26
|
end
|
27
27
|
|
28
28
|
def select_candidates(queue_relation, limit)
|
29
|
-
queue_relation.ordered.limit(limit).
|
29
|
+
queue_relation.ordered.limit(limit).non_blocking_lock.pluck(:job_id)
|
30
30
|
end
|
31
31
|
|
32
32
|
def lock_candidates(job_ids, process_id)
|
@@ -6,11 +6,11 @@ module SolidQueue
|
|
6
6
|
|
7
7
|
connects_to **SolidQueue.connects_to if SolidQueue.connects_to
|
8
8
|
|
9
|
-
def self.
|
9
|
+
def self.non_blocking_lock
|
10
10
|
if SolidQueue.use_skip_locked
|
11
|
-
|
11
|
+
lock(Arel.sql("FOR UPDATE SKIP LOCKED"))
|
12
12
|
else
|
13
|
-
|
13
|
+
lock
|
14
14
|
end
|
15
15
|
end
|
16
16
|
end
|
@@ -11,7 +11,7 @@ module SolidQueue
|
|
11
11
|
class << self
|
12
12
|
def dispatch_next_batch(batch_size)
|
13
13
|
transaction do
|
14
|
-
job_ids = next_batch(batch_size).
|
14
|
+
job_ids = next_batch(batch_size).non_blocking_lock.pluck(:job_id)
|
15
15
|
if job_ids.empty? then []
|
16
16
|
else
|
17
17
|
dispatch_batch(job_ids)
|
@@ -1,6 +1,8 @@
|
|
1
1
|
# frozen_string_literal: true
|
2
2
|
|
3
3
|
class SolidQueue::InstallGenerator < Rails::Generators::Base
|
4
|
+
source_root File.expand_path("templates", __dir__)
|
5
|
+
|
4
6
|
class_option :skip_migrations, type: :boolean, default: nil, desc: "Skip migrations"
|
5
7
|
|
6
8
|
def add_solid_queue
|
@@ -9,6 +11,8 @@ class SolidQueue::InstallGenerator < Rails::Generators::Base
|
|
9
11
|
gsub_file env_config, /(# )?config\.active_job\.queue_adapter\s+=.*/, "config.active_job.queue_adapter = :solid_queue"
|
10
12
|
end
|
11
13
|
end
|
14
|
+
|
15
|
+
copy_file "config.yml", "config/solid_queue.yml"
|
12
16
|
end
|
13
17
|
|
14
18
|
def create_migrations
|
@@ -0,0 +1,18 @@
|
|
1
|
+
#default: &default
|
2
|
+
# dispatchers:
|
3
|
+
# - polling_interval: 1
|
4
|
+
# batch_size: 500
|
5
|
+
# workers:
|
6
|
+
# - queues: "*"
|
7
|
+
# threads: 5
|
8
|
+
# processes: 1
|
9
|
+
# polling_interval: 0.1
|
10
|
+
#
|
11
|
+
# development:
|
12
|
+
# <<: *default
|
13
|
+
#
|
14
|
+
# test:
|
15
|
+
# <<: *default
|
16
|
+
#
|
17
|
+
# production:
|
18
|
+
# <<: *default
|
@@ -73,29 +73,37 @@ module SolidQueue
|
|
73
73
|
.map { |options| options.dup.symbolize_keys }
|
74
74
|
end
|
75
75
|
|
76
|
+
|
76
77
|
def load_config_from(file_or_hash)
|
77
78
|
case file_or_hash
|
78
|
-
when
|
79
|
-
|
80
|
-
when
|
81
|
-
|
82
|
-
|
79
|
+
when Hash
|
80
|
+
file_or_hash.dup
|
81
|
+
when Pathname, String
|
82
|
+
load_config_from_file Pathname.new(file_or_hash)
|
83
|
+
when NilClass
|
84
|
+
load_config_from_env_location || load_config_from_default_location
|
85
|
+
else
|
86
|
+
raise "Solid Queue cannot be initialized with #{file_or_hash.inspect}"
|
83
87
|
end
|
84
88
|
end
|
85
89
|
|
86
|
-
def
|
87
|
-
if
|
88
|
-
|
89
|
-
else
|
90
|
-
raise "Configuration file not found in #{file}"
|
90
|
+
def load_config_from_env_location
|
91
|
+
if ENV["SOLID_QUEUE_CONFIG"].present?
|
92
|
+
load_config_from_file Rails.root.join(ENV["SOLID_QUEUE_CONFIG"])
|
91
93
|
end
|
92
94
|
end
|
93
95
|
|
94
|
-
def
|
95
|
-
|
96
|
+
def load_config_from_default_location
|
97
|
+
Rails.root.join(DEFAULT_CONFIG_FILE_PATH).then do |config_file|
|
98
|
+
config_file.exist? ? load_config_from_file(config_file) : {}
|
99
|
+
end
|
100
|
+
end
|
96
101
|
|
97
|
-
|
98
|
-
|
102
|
+
def load_config_from_file(file)
|
103
|
+
if file.exist?
|
104
|
+
ActiveSupport::ConfigurationFile.parse(file).deep_symbolize_keys
|
105
|
+
else
|
106
|
+
raise "Configuration file for Solid Queue not found in #{file}"
|
99
107
|
end
|
100
108
|
end
|
101
109
|
end
|
@@ -79,7 +79,7 @@ module SolidQueue
|
|
79
79
|
end
|
80
80
|
|
81
81
|
def graceful_termination
|
82
|
-
|
82
|
+
SolidQueue.logger.info("[SolidQueue] Terminating gracefully...")
|
83
83
|
term_forks
|
84
84
|
|
85
85
|
wait_until(SolidQueue.shutdown_timeout, -> { all_forks_terminated? }) do
|
@@ -90,7 +90,7 @@ module SolidQueue
|
|
90
90
|
end
|
91
91
|
|
92
92
|
def immediate_termination
|
93
|
-
|
93
|
+
SolidQueue.logger.info("[SolidQueue] Terminating immediately...")
|
94
94
|
quit_forks
|
95
95
|
end
|
96
96
|
|
data/lib/solid_queue/version.rb
CHANGED
metadata
CHANGED
@@ -1,14 +1,14 @@
|
|
1
1
|
--- !ruby/object:Gem::Specification
|
2
2
|
name: solid_queue
|
3
3
|
version: !ruby/object:Gem::Version
|
4
|
-
version: 0.1.
|
4
|
+
version: 0.1.2
|
5
5
|
platform: ruby
|
6
6
|
authors:
|
7
7
|
- Rosa Gutierrez
|
8
8
|
autorequire:
|
9
9
|
bindir: bin
|
10
10
|
cert_chain: []
|
11
|
-
date: 2023-12-
|
11
|
+
date: 2023-12-21 00:00:00.000000000 Z
|
12
12
|
dependencies:
|
13
13
|
- !ruby/object:Gem::Dependency
|
14
14
|
name: rails
|
@@ -86,6 +86,7 @@ files:
|
|
86
86
|
- lib/active_job/queue_adapters/solid_queue_adapter.rb
|
87
87
|
- lib/generators/solid_queue/install/USAGE
|
88
88
|
- lib/generators/solid_queue/install/install_generator.rb
|
89
|
+
- lib/generators/solid_queue/install/templates/config.yml
|
89
90
|
- lib/puma/plugin/solid_queue.rb
|
90
91
|
- lib/solid_queue.rb
|
91
92
|
- lib/solid_queue/app_executor.rb
|