[rabbitmq-discuss] Ensuring low latency for publishers

Wed Feb 22 17:44:54 GMT 2012

I think I found my answer in another thread:
http://groups.google.com/group/rabbitmq-discuss/browse_thread/thread/dda41e9e8e089eaf/2c5995dc93a7a3df?lnk=gst&q=Memory+Management+Concerns+%2F+Questions#2c5995dc93a7a3df

In summary:  there's no way to know you're being throttled and no way
to timeout during a throttled publish.  That means that publishing
should be really fast! ...unless the broker's out of memory, and then
you'll be stuck waiting for an undefined amount of time.  That's a
really disappointing situation.

The solution proposed in that thread is to use a blocking queue with a
single publisher, which I threw out already due to worries about lock
contention.

On Feb 21, 10:11 am, Eric <ejare... at gmail.com> wrote:
> Thanks for the quick reply.
>
> > No. Well, there are various ways you can force it to, but by default
> > it's async.
>
> Awesome!  Great that publishing is async.
>
> > Well, you still have the one way network latency - or do you mean from
> > the point of view of the client?
>
> Right, sorry.  I mean ~0ms from the point of view of the client.  I
> don't care too much about message latency from publisher to the
> eventual consumer, just so long as the publisher doesn't experience
> any delay.
>
> > Maybe we should call it TCP flow control? But yes, if your broker is out
> > of memory, publishing will block until the broker is ready to read again.
>
> > Would you rather drop the message at this point?
>
> "TCP flow control" got me to a helpful Wikipedia article much faster,
> so maybe that's better.  :)  I would rather drop the message at that
> point.  Ideally there'd be some timeout to specify there... if I've
> been blocked for a few ms, it's time to give up.  But publisher
> throttling is supposed to be transparent to the publisher, right?
>
> On Feb 21, 9:58 am, Simon MacMullen <si... at rabbitmq.com> wrote:
>
>
>
>
>
>
>
> > On 21/02/12 17:51, Eric wrote:
> >  > First, does publishing
> >  > a message require a roundtrip to the broker?
>
> > No. Well, there are various ways you can force it to, but by default
> > it's async.
>
> >  > so I'm assuming publishing is essentially a 0ms
> >  > operation
>
> > Well, you still have the one way network latency - or do you mean from
> > the point of view of the client?
>
> >  > but I want to be sure.  Second, if the broker is throttling
> >  > via "TCP backpressure" (which I'm having a hard time finding a good
> >  > definition for) will that increase publisher latency?
>
> > Maybe we should call it TCP flow control? But yes, if your broker is out
> > of memory, publishing will block until the broker is ready to read again.
>
> > Would you rather drop the message at this point?
>
> > Cheers, Simon
>
> > --
> > Simon MacMullen
> > RabbitMQ, VMware
>
> > _______________________________________________
> > rabbitmq-discuss mailing list
> > rabbitmq-disc... at lists.rabbitmq.comhttps://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-disc... at lists.rabbitmq.comhttps://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss