[rabbitmq-discuss] Ensuring low latency for publishers

[Eric]

Well... I would find it useful.  And the person in the thread I linked
to would have found it useful as well.

It's pretty tough to go into a production environment with the
statement "Publishing should be fast unless the broker is throttling.
If the broker is throttling we won't be able to tell, we don't have a
good way of knowing beforehand, and we don't know how long the threads
will be blocked".  It's useful in any case where an application would
rather not publish the message rather than waiting to publish it
indefinitely.

The net result is that a struggling broker will cause a chain
reaction; publishers will block indefinitely, which may bring the
publishing application to a halt.  In that case I'd like to abandon
the publishing process, but it's quite impossible at that point - it's
too late, the broker is already throttling, and there's no timeout.
The thread could block for seconds, or more.  I'm concerned about not
throwing the message away, but I'm more concerned about being able to
isolate services from RabbitMQ broker events.

I know that this is solved by decoupling the publishing process, but
then I'm back to the data structure conundrum I mentioned in my first
post.  It's very elegant if a thread can simply publish a message and
move on with life, and that's only problematic if there's no guarantee
as to how long that publish can take.

One more question along this line.  The flow control document says "By
default, when the RabbitMQ server uses above 40% of the installed RAM,
it raises a memory alarm... Connection heartbeat monitoring gets
disabled too."  If I set up a connection heartbeat on the shared
connection, will the heartbeat detect a broker alarm that exceeds the
interval and disconnect?  A disconnect would terminate the publisher
channels and free things up.

 - Eric

On Feb 23, 4:15 am, Michael Bridgen <mi... at rabbitmq.com> wrote:
> On 02/23/2012 12:09 PM, Simon MacMullen wrote:
>
> > On 22/02/12 17:52, Matthew Sackman wrote:
> >>> > Is it possible to configure the broker to never page to disk so that
> >>> > it never throttles? Basically, when it hits its high watermark for
> >>> > memory can it just drop inbound messages?
> >> Nope.
>
> > I find myself wondering whether some such feature may be useful though.
> > At the moment Rabbit is concerned with never throwing anything away, how
> > many people would find it useful to drop messages when the server is busy?
>
> If data needs to be timely in preference to being reliable -- better to
> throw away data if it looks like connections are blocked, and send fresh
> data when things are clear again.
>
> -Michael
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-disc... at lists.rabbitmq.comhttps://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss