Package com.github.sonus21.rqueue.metrics

Interface RqueueQueueMetricsProvider

public interface RqueueQueueMetricsProvider
Backend-agnostic provider of queue-depth metrics. Each backend (Redis, NATS, ...) supplies its own implementation; consumers like RqueueMetrics read sizes through this interface instead of reaching into a Redis-shaped DAO.

The queueName argument is the user-facing queue name (the value bound on @RqueueListener(value="...")), not an internal storage key. Implementations are responsible for mapping it to the appropriate backend-specific key(s).

Implementations must return 0 when a queue has no messages of the requested kind (rather than throwing) so callers can use the values directly as gauge readings.

  • Method Details

    • getPendingMessageCount

      long getPendingMessageCount(String queueName)
      Number of messages waiting to be consumed from queueName — i.e. enqueued and ready for a worker to pick up, excluding messages already in-flight (processing) or scheduled for a future delivery time.

    • getScheduledMessageCount

      long getScheduledMessageCount(String queueName)
      Number of messages enqueued to queueName with a future delivery time that has not yet elapsed. Backends that don't support delayed delivery return 0.

    • getProcessingMessageCount

      long getProcessingMessageCount(String queueName)
      Number of messages currently in-flight for queueName — handed to a worker but not yet acked or nacked. Backends without an explicit in-flight set return 0.

    • getDeadLetterMessageCount

      long getDeadLetterMessageCount(String queueName)
      Number of messages in the dead-letter queue associated with queueName. Returns 0 when no DLQ is configured for the queue or the backend does not surface DLQ depth.

    • getPendingMessageCount

      default long getPendingMessageCount(String queueName, String priority)
      Priority-aware variant of getPendingMessageCount(String). The default implementation ignores priority and returns the parent queue depth, which is the right behaviour for backends that don't model per-priority sub-queues.

    • getScheduledMessageCount

      default long getScheduledMessageCount(String queueName, String priority)
      Priority-aware variant of getScheduledMessageCount(String).

    • getProcessingMessageCount

      default long getProcessingMessageCount(String queueName, String priority)
      Priority-aware variant of getProcessingMessageCount(String).

    • getPendingMessageCountByConsumer

      default long getPendingMessageCountByConsumer(String queueName, String consumerName)
      Per-consumer variant of getPendingMessageCount(String). When two @RqueueListener methods on the same queue declare different consumerName overrides, each gets its own QueueDetail and its own metric registration; backends that can report per-consumer pending depth (e.g. NATS JetStream Limits/Interest streams or any fan-out broker) should override this. The default delegates to the queue-level call so single-consumer queues, and backends without per-consumer state, behave unchanged.
      Parameters:
      queueName - user-facing queue name
      consumerName - consumer-name override from @RqueueListener(consumerName=...); null or empty when no override is set

    • getProcessingMessageCountByConsumer

      default long getProcessingMessageCountByConsumer(String queueName, String consumerName)
      Per-consumer variant of getProcessingMessageCount(String). See related javadoc.