[rabbitmq-discuss] Stop producer and queue continue growing...

Gustavo Aquino aquino.gustavo at gmail.com
Fri Mar 12 14:36:31 GMT 2010


This is my biggest concern.

Look about this scenario I have one Exchange and one persistent queue.I'm
posting transient messages to this Exchange (to get better performance) if
my Exchanges messages are in buffer and server crash I will be loose all
messages in buffer and it is a big problem.... I cannot lose any messages,
this messages are business it represent money, so if I loose one we loose
money and It cannot happen, in other way I need to be the fastest we
need overrides in nanoseconds or 1 millisecond is the limit, so post
messages in persistent queue is out of the scope, or  have one way to be
fast with persistent ?

My questions is, looking for this requirements (don't loose any message and
be fastest) RabbitMQ attend this ? Have a way to attend this requirements ?

Regards.


On Fri, Mar 12, 2010 at 9:30 AM, Matthew Sackman <matthew at lshift.net> wrote:

> On Fri, Mar 12, 2010 at 09:17:22AM -0300, Gustavo Aquino wrote:
> > If I have one persistent queue binding this Exchange where messages was
> > posted and all of this messages are in buffer going to queue and server
> > crash so I will lose all this buffered messages right ?
>
> Correct. Transactions exist for a reason. Publishing is an async
> activity and you as the producer have (almost) no idea whether it's even
> hit a queue, let alone whether it's gone to disk. Furthermore, even if
> it's gone to disk, you have no idea if it's been flushed from the disk
> caches and so can really survive a powerfailure to the server.
>
> If you use transactions, however, then by the time you get back the
> commit_ok messages, you are *guaranteed* that the persistent messages
> have been written to disk and flushed. Correspondingly, performance is
> crippled, though the transaction handling in the new persister branch
> (bug21673) is much better (anywhere up to 2 orders of magnitude,
> depending on disks and filesystem tuning) than in the released versions
> of Rabbit.
>
> 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/20100312/b489ea85/attachment.htm 


More information about the rabbitmq-discuss mailing list