Skip to content

Releases: thread/django-lightweight-queue

v4.11.0

18 Nov 11:57
Compare
Choose a tag to compare
  • Support specifying the Redis Database to use. Since this package uses Redis' KEYS command, which is potentially slow if there are lots of keys in the database, this provides a way to partition a Redis instance to avoid other uses creating performance issues for DLQ.

v4.10.1

18 Nov 11:47
Compare
Choose a tag to compare
  • Fix handling of --yes argument in queue_clear

v4.10.0

14 Nov 18:14
Compare
Choose a tag to compare
  • Pass through --extra-settings to worker processes, so that they obey any extra configuration passed that way; fixes #78
  • Add a new queue_clear management command which empties a given queue of jobs (this is a potentially destructive action)

v4.9.0

14 Nov 18:10
Compare
Choose a tag to compare

v4.8.0

07 Sep 14:31
Compare
Choose a tag to compare
  • Revert the reliable Redis backend to use KEYS instead of SCAN when starting up as SCAN turned out to have worse performance impacts than KEYS in real-world usage.

v4.7.0

23 Aug 09:34
Compare
Choose a tag to compare
  • Update the reliable Redis backend to use SCAN instead of KEYS when starting up to avoid blocking the Redis instance when many workers nodes start in a short amount of time.

v4.6.0

15 Aug 15:26
Compare
Choose a tag to compare
  • Adds support for Django 4 in the Debug Web backend (thanks @itsthejoker)
  • Moves from using imp to importlib to load "extra" settings
  • Adds logging of jobs timeouts for better observability
  • potentially breaking Drops support for Python 3.5

v4.5.1

24 Jun 08:59
Compare
Choose a tag to compare

Adds missing typing-extensions dependency.

Thanks @itsthejoker for reporting.

v4.5.0

13 Jun 17:32
Compare
Choose a tag to compare

Fixes a couple of deprecation warnings:

  • no longer exports a default_app_config above Django 3.2
  • moves from using imp to importlib in concert with Django's import helpers for task discovery

v4.4.1

11 Feb 10:05
Compare
Choose a tag to compare

Makes the background CronScheduler thread resilient to errors which happen during its tick function. Previously these errors would bubble to the top of the thread, causing it to exit. As the master process doesn't monitor the cron thread this would result in no cron tasks being enqueued until the master was restarted.