We're still developing our infrastructure, so that's not an issue.<br><br>Thanks.<br><br>- Jim<br><br clear="all">Jim Irrer <a href="mailto:irrer@umich.edu">irrer@umich.edu</a> (734) 647-4409<br>University of Michigan Hospital Radiation Oncology<br>
519 W. William St. Ann Arbor, MI 48103<br>
<br><br><div class="gmail_quote">2009/10/7 Holger Hoffstätte <span dir="ltr"><<a href="mailto:holger.hoffstaette@googlemail.com">holger.hoffstaette@googlemail.com</a>></span><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="im">Jim Irrer wrote:<br>
> Someone must have bumped into this problem before, but what is a<br>
> good strategy for transferring very large buffers (tens or even<br>
> hundreds of megabytes)? No matter how the server is configured,<br>
> a message could be sent that is too large to handle.<br>
<br>
</div>The typical approach is to take the broker out of the critical path and<br>
only send metadata, i.e. the necessary information for a client to<br>
retrieve the payload: file path, url, encoding (e.g. compression), size<br>
(to allow for up front allocation and possibly rejection in case the local<br>
node is not up for it) etc. so that the consumer can pick up the big<br>
message by itself.<br>
This also implies that all clients need to be able to distinguish between<br>
regular payloads and proxy messages, so adding this late to an<br>
architecture can be difficult..<br>
<br>
-h<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>
</blockquote></div><br>