This is my biggest concern.<div><br></div><div>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 ?</div>
<div><br></div><div>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 ?</div><div><br></div><div>Regards.</div><div><br>
<br><div class="gmail_quote">On Fri, Mar 12, 2010 at 9:30 AM, Matthew Sackman <span dir="ltr"><<a href="mailto:matthew@lshift.net">matthew@lshift.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Fri, Mar 12, 2010 at 09:17:22AM -0300, Gustavo Aquino wrote:<br>
> If I have one persistent queue binding this Exchange where messages was<br>
> posted and all of this messages are in buffer going to queue and server<br>
> crash so I will lose all this buffered messages right ?<br>
<br>
</div>Correct. Transactions exist for a reason. Publishing is an async<br>
activity and you as the producer have (almost) no idea whether it's even<br>
hit a queue, let alone whether it's gone to disk. Furthermore, even if<br>
it's gone to disk, you have no idea if it's been flushed from the disk<br>
caches and so can really survive a powerfailure to the server.<br>
<br>
If you use transactions, however, then by the time you get back the<br>
commit_ok messages, you are *guaranteed* that the persistent messages<br>
have been written to disk and flushed. Correspondingly, performance is<br>
crippled, though the transaction handling in the new persister branch<br>
(bug21673) is much better (anywhere up to 2 orders of magnitude,<br>
depending on disks and filesystem tuning) than in the released versions<br>
of Rabbit.<br>
<div><div></div><div class="h5"><br>
Matthew<br>
<br>
_______________________________________________<br>
rabbitmq-discuss mailing list<br>
<a href="mailto:rabbitmq-discuss@lists.rabbitmq.com">rabbitmq-discuss@lists.rabbitmq.com</a><br>
<a href="http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br>
</div></div></blockquote></div><br></div>