Skip to content

Releases: sonus21/rqueue

Apis to enqueue messages

17 May 13:56

Choose a tag to compare

  1. Fixed issue in queue deletion
  2. Fixed bug of argument mismatch
  3. New apis to enqueue messages using enqueueAt
  4. Refined apis for enqueueIn using Duration, TimeUnit

Version 2.0.0

10 May 13:25

Choose a tag to compare

New Features

  • Web Interface
    • Web interface to visualize queue
    • Latency visualizer
    • Delete message from the queue
    • Move message from one queue to another
  • Allow prefixing redis keys to avoid accidental key delete
  • Allow deactivating a consumer in a given environment
  • Redis cluster support
  • Queue concurrency
  • Queue priority (Weighted and strict)
  • Queue priority at group level
  • Queue priority at sub queue level like critical, high, medium, low

Breaking Changes

  • Queue names are prefixed, version 1.0 users need to set a redis key __rq::version with value 1
  • Renamed annotation field maxJobExecutionTime to visibilityTimeout

Fixes

  • Spring Optional Micrometer, in older version config class was importing micrometer related classes, that could lead to error if classes are not found. In this version now code depends on bean name using DependsOn annotation.
  • Complete isolation of Redis, allow application to configure one Redis for the application and one for the Rqueue

Queue metrics

11 Dec 15:50

Choose a tag to compare

  1. Expose 6 queue metrics using micrometer. (queue-size, delay queue size, processing queue size, dead letter queue size, execution counter, failure counter)
  2. Fix an issue in scheduler that's getting scheduled at the delay of 5 seconds. [this leads to messages are not copied from delayed queue to main queue on high load.
  3. An api to move messages from dead letter queue to other queue (any source queue to target queue).

Rqueue

18 Nov 06:17
3d818f3

Choose a tag to compare

  • A message can be delayed for an arbitrary period of time or delivered immediately.
  • Multiple messages can be consumed in parallel by different workers.
  • Message delivery: It's guaranteed that a message is consumed at least once. (Message would be consumed by a worker more than once due to the failure in the underlying worker/restart-process etc, otherwise exactly one delivery)