You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+31-1Lines changed: 31 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -208,17 +208,47 @@ Finally, run the migrations:
208
208
$ bin/rails db:migrate
209
209
```
210
210
211
+
## Lifecycle hooks
212
+
213
+
In Solid queue, you can hook into two different points in the supervisor's life:
214
+
- `start`: after the supervisor has finished booting and right before it forks workers and dispatchers.
215
+
- `stop`: after receiving a signal (`TERM`, `INT` or `QUIT`) and right before starting graceful or immediate shutdown.
216
+
217
+
And into two different points in a worker's life:
218
+
- `worker_start`: after the worker has finished booting and right before it starts the polling loop.
219
+
- `worker_stop`: after receiving a signal (`TERM`, `INT` or `QUIT`) and right before starting graceful or immediate shutdown (which is just `exit!`).
220
+
221
+
You can use the following methods with a block to do this:
222
+
```ruby
223
+
SolidQueue.on_start
224
+
SolidQueue.on_stop
225
+
226
+
SolidQueue.on_worker_start
227
+
SolidQueue.on_worker_stop
228
+
```
229
+
230
+
For example:
231
+
```ruby
232
+
SolidQueue.on_start { start_metrics_server }
233
+
SolidQueue.on_stop { stop_metrics_server }
234
+
```
235
+
236
+
These can be called several times to add multiple hooks, but it needs to happen before Solid Queue is started. An initializer would be a good place to do this.
237
+
238
+
211
239
### Other configuration settings
212
240
_Note_: The settings in this section should be set in your `config/application.rb` or your environment config like this: `config.solid_queue.silence_polling = true`
213
241
214
242
There are several settings that control how Solid Queue works that you can set as well:
215
243
- `logger`: the logger you want Solid Queue to use. Defaults to the app logger.
216
244
- `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
217
-
- `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
245
+
- `on_thread_error`: custom lambda/Proc to call when there's an error within a Solid Queue thread that takes the exception raised as argument. Defaults to
**This is not used for errors raised within a job execution**. Errors happening in jobs are handled by Active Job's `retry_on` or `discard_on`, and ultimately will result in [failed jobs](#failed-jobs-and-retries). This is for errors happening within Solid Queue itself.
251
+
222
252
- `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.
223
253
- `process_heartbeat_interval`: the heartbeat interval that all processes will follow—defaults to 60 seconds.
224
254
- `process_alive_threshold`: how long to wait until a process is considered dead after its last heartbeat—defaults to 5 minutes.
0 commit comments