Releases: QueueClassic/queue_classic
4.0.0
4.0.0 Beta 1
We've had an alpha for a while. This fixes a couple of minor issues with it, including
- Fixes Postgres 14 support (dbfee9b, @jhawthorn)
- Added more testing for ruby versions - more coming soon (76ad0b2, @faraquet)
- Guards against timestamp issues with Rails (6ab7dfa, Fonacier)
4.0.0 Alpha 2
Update to currently supported ruby versions (#323) * Update to currently supported ruby versions * Fix the circle yml * Change to always test the latest releases of 2.4, 2.5, 2.6
4.0.0 Alpha 1
Tons of changes here, but the main one is moving to use SKIP LOCKED, which improves performance dramatically.
v3.1.0
Signal Processing & QUEUES Fix
Improved signal handling. Worker now unlocks jobs when the INT signal is processed. Also fixed issues with the worker reading the values of $QUEUES
for multi-queue processing.
Worker can process many queues
The new feature in this release is the ability for a worker to process many queues. The worker will accept a list of queues to work on and will process the queues in a left to right order. For example:
$ QUEUES="first,second" bundle exec rake qc:work
In this scenario, on each iteration of the worker's loop, it will look for jobs in the first
queue prior to looking at the second
queue. This means that the first
queue must be empty before the worker will look at the second
queue.
See 2fefa5f for more details. And more generally read over #190 for an overview of the refactorings.
PG Bump
Bumped pg gem dependency to 0.17.0. Notes on the pg change can be found here: https://bitbucket.org/ged/ruby-pg/src/9812218e0654caa58f8604838bc368434f7b3828/History.rdoc?at=default#cl-1
yanked - Concurrent Worker
This release was pulled because it was fundamentally flawed.
This release boasts one new feature: Concurrent Job Processing.
Concurrency in the worker is achieved by forking child processes to carry out the execution of jobs. The parent worker process will dequeue a job from the queue and fork a new process to carry out job execution. The parent process is capable of handling many dequeue/fork operations concurrently up to a defined maximum level of concurrency. The control for the max number of child processes is controlled the by QC_CONCURRENCY
environment variable. The forking implementation has the side effect of increasing the number of connections to the database, so caution should be exercised.
$ QC_CONCURRENCY=4 bundle exec rake qc:work