<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Dec 28, 2011, at 19:48 , Tony Garnock-Jones wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div class="gmail_quote">On 28 December 2011 12:49, Srdan Kvrgic <span dir="ltr"><<a href="mailto:srdan@burtcorp.com">srdan@burtcorp.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
My question is as simple as it is complex: 'Is that it?' What can I do to tweak these numbers? Massively.<br></blockquote><div><br>Is this a transient-messaging use case (RabbitMQ as router, not relying particularly on disk storage), or a persistent-messaging use case (where you die in flames if a single message is dropped), or somewhere in-between?<br></div></div></blockquote></div><br><div>Well, it is transient in so fact that we use it to distribute messages to a large number of workers. In that way it is a router. But it also functions as a buffer. If we for instance update the workers we like to be able to stop and restart them without throwing messages away. </div><div><br></div><div>Each individual message is not that important in itself. And if we loose a larger amount of messages, we can re-queue the affected blocks. We're big on idempotence and can cut ourselves some slack if we need to.</div><div><br></div><div>That said, once you get to sending thousands of messages per second and the system goes all fishy on you for an indeterminate length of time, the re-queueing becomes… inconvenient. Inconvenient to the degree that it for most practical purposes stops being an option and you become prepared to 'invest' yourself away from those problems if at all possible.</div><div><br></div><div><br></div><div>//S</div></body></html>