[rabbitmq-discuss] Ensuring low latency for publishers

[Eric]

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?

On Feb 22, 9:44 am, Eric <ejare... at gmail.com> wrote:
> I think I found my answer in another thread:http://groups.google.com/group/rabbitmq-discuss/browse_thread/thread/...
>
> 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
>
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-disc... at lists.rabbitmq.comhttps://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss