[rabbitmq-discuss] Consumer stop to receive messages but continue listening queue problem.

[Gustavo Aquino]

Hi,

I come back here about this assumption, it's a big concern today for us.

Let's explain the facts.

We have 1 exchange e 1 persistent queue binding for routing key = book.APPL

We have a publisher putting messages from exchange, each message have ~213
bytes and each routing key identify the goup of message like book.APPL,
book.PETR4 and etc. We are publishing about ~3000 m/s

We have one consumer listening queue.

The problem.

We put test to run for 1 hour, and monitoring queue size with rabbitmqctl
list_queues, all the time list have 0 size, so consumer are getting all on
the fly, and now we stop publisher and here is the BIG PROBLEM, consumer
continue to consume messages from queue... and it's remain for 20 minutes
after stop publisher......

If we stop consumer we can see the queue growing for long time..., therefore
looking for it's we can conclude that our consumer are 20 minutes late
behind publisher and it's a f... problem last message from publisher will be
received by consumer just 20 minutes after.

About environments.

We are using a P550 Machine with 4 PPC64 processors 5.4Ghz, and 100Gb of
ram, during our tests it's have just 20% of processor busy, and 2Gb of
memory allocated.

We are using Red Hat 5 for ppc in our tests.

We replicate this scenario using Intel x86_64 with Red Hat linux for 64bits,
and Real Time Kernel, this machine have 8 cores and 32Gb of ram, and during
the tests it consume just 25% of CPU and 2Gb of ram.

So can anyone help me ? Its's a common problem in Rabbit ? anybody here have
this same problem ? We have talked about a possible exchange buffer cause
and etc in this way, but to be sincerely in my thoughts ~3000 m/s is a bit
easy to be processed for one message server.

Gustavo.





On Fri, Mar 26, 2010 at 5:15 PM, Bryan Murphy <bmurphy1976 at gmail.com> wrote:

> Make sense, although we don't care about the order so it doesn't affect us
> so much.
>
> Bryan
>
>
> On Fri, Mar 26, 2010 at 1:11 PM, Matthew Sackman <matthew at lshift.net>wrote:
>
>> Hi,
>>
>> On Fri, Mar 26, 2010 at 08:33:19AM -0500, Bryan Murphy wrote:
>> > Another technique we use:
>> >
>> > Start one consumer.
>> >
>> > Start your other consumers.
>> >
>> > Restart the first consumer.
>> >
>> > This let's you keep the high prefetch settings while still getting the
>> > messages to distribute more evenly.
>>
>> I would not recommend that at all - you're likely to get messages in
>> different orders with this scheme. QoS is much better idea, or, use
>> channel.flow from the client (may only work in newer-than-1.7.2 - can't
>> remember when it appeared) to prevent any messages being sent out
>> *before* issuing the basic.consume.
>>
>> You could then have either a delay or some signal through some other
>> exchange and queues (and channel) to get the clients to drop the
>> channel.flow and start consuming.
>>
>> Matthew
>>
>
>
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100518/e9420aaa/attachment-0001.htm