<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">It's been languishing in a corner for several months since I've been rather busy, but I wrote a "job scheduler" utility for RabbitMQ at a previous employer. It has a bunch of different things in it but one of them is a BatchMessageHandler. It listens for zip files coming in, unzips them, dumps them into a broker, collects the results, zips them up, then responds to the sender with a zip file of results.<div><br></div><div>This was to take the place of a somewhat similar system they have where requests from remote WAN nodes are batched, zipped and sent to the datacenter to be executed by a proxy (because of slow WAN pipes).</div><div><br></div><div>I'd like to revisit some of this code at some point because there's some pretty neat functionality here, I think, and it could use some love to update it to the latest spring-amqp version and whatnot.</div><div><br></div><div>It's not an "unzip it and run it" thing, but it might be a jumping-off point for something like what you describe.</div><div><br></div><div><div><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: 'Times New Roman'; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><br>Thanks!<br><br>Jon Brisbin<br><br><a href="http://jbrisbin.com">http://jbrisbin.com</a><br>Twitter: @j_brisbin<br><br></span></div><div><br><div><div>On Apr 28, 2011, at 1:01 PM, Gene Campbell wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Thank you for the response. Great one for a FAQ. The confirmation of batching and compression not being in Shovel is something we until now we couldn't confirm. (Therefore it's usefulness to us just dropped a bit.)<br>
<br>The value of being able to ACK back fast, and let a client continue on, while giving some comfort going forward that the message will actually be consumed somewhere after some length of time. For example, if you can stand 1 minute of latency from publish to consume, but you're client needs an ACK, it will need to store potentially large amounts of data (if your link goes down) until it gets the ACK (link comes back up and message consumed.) With shovel, it can get a quicker ACK.<br>
<br>Thanks<br>Gene<br><br><div class="gmail_quote">On Thu, Apr 28, 2011 at 5:22 AM, Matthew Sackman <span dir="ltr"><<a href="mailto:matthew@rabbitmq.com">matthew@rabbitmq.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;">
Hi,<br>
<div><div></div><div class="h5"><br>
On Sun, Apr 24, 2011 at 02:13:13PM -0700, ristretto.rb wrote:<br>
> Suppose there are two servers connected across a WAN (read internet),<br>
> sending transient messages, with all else held constant what is the<br>
> faster method in terms of messages / sec: Two brokers and a Shovel,<br>
> one broker with a remote publisher, or one broker with a remote<br>
> consumer. (The last two cases might be really just one case.)<br>
><br>
> msg -> X -> Q -> Shovel -> X -> Q -> Consume<br>
> vs<br>
> msg ---------------------------> X -> Q -> Consume<br>
><br>
> What if durability is required? Does this change the decision?<br>
<br>
</div></div>Regardless of whether you're using the shovel or not, over the WAN link<br>
will flow AMQP msgs over TCP/IP. There is no compression or any batching<br>
used by shovel, so your throughput and latency won't be different in any<br>
of the combinations you suggest.<br>
<br>
However, you might wish for, eg the publisher to very quickly be able to<br>
publish a msg and get a confirmation back that the msg has been<br>
published and accepted by the broker. If the latency of this operation<br>
is important then it makes sense to have the broker near the publisher.<br>
<br>
The next thing to consider is whether it's actually going to make any<br>
difference to the consumer whether or not it's got a broker very near<br>
it. For example, is it going to be doing any synchronous operations<br>
regularly. If not (i.e. it's just receiving msgs and acking them), then<br>
there probably isn't much difference whether it's connected to a local<br>
broker or a remote one.<br>
<font color="#888888"><br>
Matthew<br>
</font><div><div></div><div class="h5">_______________________________________________<br>
rabbitmq-discuss mailing list<br>
<a href="mailto:rabbitmq-discuss@lists.rabbitmq.com">rabbitmq-discuss@lists.rabbitmq.com</a><br>
<a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br>
</div></div></blockquote></div><br>
_______________________________________________<br>rabbitmq-discuss mailing list<br><a href="mailto:rabbitmq-discuss@lists.rabbitmq.com">rabbitmq-discuss@lists.rabbitmq.com</a><br>https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss<br></blockquote></div><br><div><br></div></div></div></body></html>