[rabbitmq-discuss] Stop producer and queue continue growing...
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 ?
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.
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rabbitmq-discuss