We've been testing "big messages" in the queues for the last 24h (yes it's short) and so far, so good!<br><br>Thanks all for your help, I'll let you know if we have anything wrong.<br><br>Thx,<br><br clear="all">
--<br>Julien Genestoux<br><a href="http://www.ouvre-boite.com">http://www.ouvre-boite.com</a><br><a href="http://blog.notifixio.us">http://blog.notifixio.us</a><br><br>+1 (415) 254 7340<br>+33 (0)9 70 44 76 29<br>
<br><br><div class="gmail_quote">On Sat, Jan 10, 2009 at 11:42 PM, Tony Garnock-Jones <span dir="ltr"><<a href="mailto:tonyg@lshift.net">tonyg@lshift.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
My question is the following : instead of queuing the file names (and storing the files locally), is it<br>
possible to queue the full files content itself? Given that the file have a<br>
of under 200k?<br>
</blockquote>
<br></div>
That sounds like it should work without any problems. There are no built-in limits on the sizes of individual messages (besides the 64-bit body size in the AMQP protocol), and the STOMP adapter should cope just fine.<br>
<br>
The only thing that might hold you up is the way the broker holds all queued messages in RAM in its current version. If you want to have more queued data than that, we recommend either getting more RAM :-) or helping out with alterations to make spooling-to-disk smooth and tasty.<br>
<br>
Let us know how your experiments go!<br>
<br>
Regards,<br><font color="#888888">
Tony<br>
<br>
</font></blockquote></div><br>