<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">&lt;<a href="mailto:srdan@burtcorp.com">srdan@burtcorp.com</a>&gt;</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.&nbsp;</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>