[rabbitmq-discuss] Slow consumer disconnect availability on RAbbitMQ

[Jerry Kuch]

Hi, Prashant...

> Do we have slow consumer detection available in RabbitMQ like we have
> in Apache qpid ( Slow Consumer Disconnect (SCD) is a new feature in
> Qpid that provides a configurable mechanism to prevent a single slow
> consumer from causing a back up of unconsumed messages on the broker )

Possibly, but can I ask a couple of questions about your actual use
case?  First, are you actually seeing cases where your consumers are
so slow that the broker's own self defense mechanisms like paging
messages to disk and memory-based producer flow control either aren't
engaging, or are being overwhelmed in some way?  Second, are you sure
you actually want to disconnect clients that are consuming slowly, but
whose connections are otherwise alive and healthy?

> This is a very nice feature wherein we could identify and take
> corrective actions against the consumer. Please suggest any
> alternative method to achieve this behavior. Also when we identify SCD
> can we defer the queue for some time( timed defer) before it comes
> back to service something like suspend Queue for 5 mins and try
> again.

I presume that one of the requirements of the behavior you desire
would be that you discard messages from a queue whose consumers aren't
keeping up to its load since simply disconnecting a slow consumer
without some ability to replace it by one or more less slow ones isn't
going to help.  In that case, you could try the per-queue message TTL
extension that Rabbit supports.  It's documented here:

http://www.rabbitmq.com/extensions.html#queue-ttl

This lets you declare queues with a limit on how long a message
published to a queue can remain there before it is discarded.  This
would let you escape the back up of unconsumed messages that you're
concerned about and, for many types of message flows, is a sensible
behavior in any event since the relevance of ancient messages that
have been languishing unconsumed in queues probably degrades with time
anyway.

Best regards,
Jerry