1.17.0 - Add Meter for in-progress jobs

What's Changed

🚨The jobDurationTimer metric has been updated to use milliseconds rather than seconds.

Add Meter for in-progress jobs by @ptoffy in #139

This adds a Meter metric to record the number of jobs currently being processed by a worker.
The gauge also allows calculation of not yet processed but enqueued jobs, since we can now do

notYetProcessedJobs = dispatchedJobsCount - (errorCompleted + successCompleted) - inProgressJobs

Reviewers

Thanks to the reviewers for their help:

• @maciejtrybilo

This patch was released by @ptoffy

Full Changelog: 1.16.1...1.17.0

1.16.1 - Fix usage of the Metrics Timer.

What's Changed

Fix usage of the Metrics Timer. by @maciejtrybilo in #135

When using the Timer aggregate the measurements by status and job name rather than by status and job id.

Job id is unique to each job run and therefore in the current implementation a new summary is created for each job run which doesn’t collect useful metrics data and causes excessive memory usage.

Reviewers

Thanks to the reviewers for their help:

• @ptoffy

This patch was released by @0xTim

Full Changelog: 1.16.0...1.16.1

1.16.0 - Added dependency to `swift-metrics`

What's Changed

Added dependency to swift-metrics by @ptoffy in #117

Added a dependency to swift-metrics to be able to record metrics on queues.

Metrics added:

• Timer to see how long a job takes to complete
• Counter to keep track of dispatched jobs
• Two different counters to keep track of successes and failures

This patch was released by @0xTim

Full Changelog: 1.15.1...1.16.0

1.15.1 - Run until no more work is pending

What's Changed

Run until no more work is pending by @danpalmer in #134

First pass at fixing #124.

Currently, every refresh interval, workers run a single task. This means that the maximum task throughput in the refresh interval is the number of workers.

With this change, every refresh interval, workers run tasks until there are no more tasks. This means that task throughput is tied to the speed of processing tasks, rather than just the number of workers.

Open to feedback about the approach, and I haven’t added any tests here yet. This is a fairly major behavioural change, but should result in a large speed increase for most users.

This patch was released by @0xTim

Full Changelog: 1.15.0...1.15.1

1.15.0 - Making Queues `Sendable`

What's Changed

Making Queues Sendable by @gwynne in #129

The Queues package is now Sendable-correct. Also includes a number of fixes:

• Swift minimum version is now 5.8 of course
• QueuesCommand now does signal handling the same way ServeCommand does.
• The logging is much more consistent and is fully structured
• QueueWorker now handles retries in a much more consistent fashion and always requeues.
• AsyncQueue now exists for creating Concurrency-based drivers

Reviewers

Thanks to the reviewers for their help:

• @MahdiBM
• @0xTim

This patch was released by @gwynne

Full Changelog: 1.14.0...1.15.0

1.14.0 - Adopt Async Lifecycle Handler

What's Changed

Adopt Async Lifecycle Handler by @0xTim in #132

Adopt Vapor’s asynchronous LifecycleHandler APIs to avoid calling .wait() in the main application flow

This patch was released by @0xTim

Full Changelog: 1.13.0...1.14.0

1.13.0 - Misc cleanups

What's Changed

Misc cleanups by @gwynne in #123

• Update Swift minimum version to 5.6 to match Vapor
• CI updates

Reviewers

Thanks to the reviewers for their help:

• @MahdiBM

This patch was released by @gwynne

Full Changelog: https://github.com//compare/1.12.1...1.13.0

Add missing platform specifiers

This patch was authored and released by @gwynne.

Match Vapor's support

Add async job hooks

This patch was authored by @madsodgaard and released by @0xTim.

• Bump Swift version to 5.5.2
• Backport concurrency to older platforms
• Add AsyncJobEventDelegate for async hooks
• Replace Lock with NIOLock

Fix typos in QueueWorker log messages

This patch was authored by @heldersrvio and released by @jdmcd.

Fixes a few typo'd log messages.