<br><div class="gmail_quote">On Thu, Jul 15, 2010 at 4:24 PM, Andreas Jung <span dir="ltr"><<a href="mailto:lists@zopyx.com">lists@zopyx.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<div><div></div><div class="h5"><br>
Darius Damalakas wrote:<br>
><br>
> > I think you should use some flow control. If your Rabbit has the<br>
> memory<br>
> > alerts turned on, then your producer can pick up the<br>
> > channel.flow/active=false and stop sending until you get the<br>
> active=true.<br>
> ><br>
> > Otherwise your sending of persistent message will eventually make<br>
> Rabbit run<br>
> > out of resources.<br>
><br>
><br>
> IMHO, If it is not possible to store big amounts of messages, that will<br>
> require storing them somewhere else. Which basically means implementing<br>
> messaging logic twice.<br>
><br>
> Is there a possibility to use a different database back-end for<br>
> persisting messages?<br>
><br>
<br>
<br>
<br>
</div></div>Shall we learn from this thread that RabbitMQ can not deal 200k message<br>
with a size of 300 bytes in a reasonable way? That's not much data.<br>
<br>
- -aj<br>
<br></blockquote><div><br>Sorry I can't be of more help with regards the actual resource usage pattern that is seen here (I'm still on 1.6). Maybe someone from the team will jump in at some point.<br><br>My hunch would be that the underlying DB is flushing the logs and that is eating up your CPU. If that was then killed mid flush, the next start up will start repairing your DB, also eating up your CPU. The logfile will probably contain something that will help diagnose this further.<br>
<br>@Ovidiu:<br>BUT, are you really sure you want what you are asking for? If I understand you correctly you want to allow outside producers (not under your control) to send persistant messages directly into your RabbitMQ and not have those producers back off?<br>
<br>Personally, I think that is not achievable. At some point your server is going to reject messages, and your producers must be able to deal with that, if, as you say, no messages are allowed to be lost.<br><br>Robby<br>
<br></div></div>