<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7654.12">
<TITLE>RE: Slow consumer disconnect availability on RAbbitMQ</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>Hi Jerry,<BR>
<BR>
Thanks for getting back.<BR>
<BR>
Actually we do have a requirement where I want consumer to stop getting message once I know that its slow( my consumption logic connects to remote server and if server is not responding or is slow for any reason I dont want my queue to get clogged), I would want to stop queue from populating.<BR>
<BR>
The catch here is , I too dont want to purge all the messages or drop it . I too tried to use TTL and queue lease , but am not sure about messages resisding in the queue i.e whether they are requed or silently dropped( in my case I want them to by returned back to exchange and make the queue alive after some duration)<BR>
<BR>
N.B: I guess suspending the queue can be little tricky , let me know yout thoughts<BR>
<BR>
Regds<BR>
Prashant<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: Jerry Kuch [<A HREF="mailto:jerryk@vmware.com">mailto:jerryk@vmware.com</A>]<BR>
Sent: Wed 1/26/2011 11:45 PM<BR>
To: Prashant Yadav; rabbitmq-discuss@lists.rabbitmq.com<BR>
Subject: RE: Slow consumer disconnect availability on RAbbitMQ<BR>
<BR>
Hi, Prashant...<BR>
<BR>
> Do we have slow consumer detection available in RabbitMQ like we have<BR>
> in Apache qpid ( Slow Consumer Disconnect (SCD) is a new feature in<BR>
> Qpid that provides a configurable mechanism to prevent a single slow<BR>
> consumer from causing a back up of unconsumed messages on the broker )<BR>
<BR>
Possibly, but can I ask a couple of questions about your actual use<BR>
case? First, are you actually seeing cases where your consumers are<BR>
so slow that the broker's own self defense mechanisms like paging<BR>
messages to disk and memory-based producer flow control either aren't<BR>
engaging, or are being overwhelmed in some way? Second, are you sure<BR>
you actually want to disconnect clients that are consuming slowly, but<BR>
whose connections are otherwise alive and healthy?<BR>
<BR>
> This is a very nice feature wherein we could identify and take<BR>
> corrective actions against the consumer. Please suggest any<BR>
> alternative method to achieve this behavior. Also when we identify SCD<BR>
> can we defer the queue for some time( timed defer) before it comes<BR>
> back to service something like suspend Queue for 5 mins and try<BR>
> again.<BR>
<BR>
I presume that one of the requirements of the behavior you desire<BR>
would be that you discard messages from a queue whose consumers aren't<BR>
keeping up to its load since simply disconnecting a slow consumer<BR>
without some ability to replace it by one or more less slow ones isn't<BR>
going to help. In that case, you could try the per-queue message TTL<BR>
extension that Rabbit supports. It's documented here:<BR>
<BR>
<A HREF="http://www.rabbitmq.com/extensions.html#queue-ttl">http://www.rabbitmq.com/extensions.html#queue-ttl</A><BR>
<BR>
This lets you declare queues with a limit on how long a message<BR>
published to a queue can remain there before it is discarded. This<BR>
would let you escape the back up of unconsumed messages that you're<BR>
concerned about and, for many types of message flows, is a sensible<BR>
behavior in any event since the relevance of ancient messages that<BR>
have been languishing unconsumed in queues probably degrades with time<BR>
anyway.<BR>
<BR>
Best regards,<BR>
Jerry<BR>
<BR>
</FONT>
</P>
</BODY>
</HTML>