[rabbitmq-discuss] Publisher Confirms stop occurring when Consumer is present and queue is large

[Cameron Davison]

Matthew,

Thank you for the reply. Do y'all have a bug tracker that I would be
able to watch so that I can know when y'all address this issue? Do you
know if this same thing would be even worse for a mirrored queue
rabbit mq cluster? I am seeing a lot of degradation in write
throughput while reading when doing mirrored queue cluster. All I
really want is high availability such that if one server crashed the
slave in the cluster will become the master and allow for continued
throughput. Is this the correct way to that?

Cameron

On Tue, Nov 1, 2011 at 1:31 AM, Matthew Sackman <matthew at rabbitmq.com> wrote:
> Hi Cameron,
>
> Thanks for the detailed report.
>
> Your report has prompted us to think carefully about your test, and we
> can see how the broker can end up behave this way. This is not desired
> behaviour of the broker and thus does constitute a bug. There is no
> work-around.
>
> What is happening is that your publisher is waiting for the broker to
> send the confirms back to it. For this to happen, internally, the queues
> have to send some messages to themselves. These messages are being
> starved out because Rabbit prioritises getting rid of messages. Thus the
> queue's desire to drive the consumer prevents the queue from processing
> internal messages that would lead the queue to issue the confirms back
> up, via the channel and out to the client.
>
> At a minimum, we need to adjust some message priorities internally. But
> the actual fix may turn out to be bigger than that. Given current
> timings, I wouldn't expect a fix for this to be in the next release, but
> in the one after that.
>
> Best wishes,
>
> Matthew
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>