<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">The consumer would need to be more<br>intelligent, but what criteria you use for deciding you've had enough replies<br>
and how to 'package' them up as a single response to the original request is<br>very application-specific, I think.<br></blockquote>
<div>In my implementation, this criteria is simply an "expected number of responses". Here is the prototype of the function I am using (note that a list of byte arrays is provided, all of them sent to the same exchange/routing key, so that I can send several tasks to each shard at once).</div>
<div> </div>
<div>Typically, you'll have numberOfExpectedResponse=bodies.size() * numberOfShards;</div><b><font color="#7f0055" size="2"><font color="#7f0055" size="2">
<p>public</p></font></font></b><font size="2"> List<</font><b><font color="#7f0055" size="2"><font color="#7f0055" size="2">byte</font></font></b><font size="2">[]> rpcCall(</font><b><font color="#7f0055" size="2"><font color="#7f0055" size="2">final</font></font></b><font size="2"> String messageId, </font><b><font color="#7f0055" size="2"><font color="#7f0055" size="2">final</font></font></b><font size="2"> String exchange, final String routingKey, </font><b><font color="#7f0055" size="2"><font color="#7f0055" size="2">final</font></font></b><font size="2"> List<byte[]> bodies, </font><b><font color="#7f0055" size="2"><font color="#7f0055" size="2">final</font></font></b><font size="2"> </font><b><font color="#7f0055" size="2"><font color="#7f0055" size="2">int</font></font></b><font size="2"> numberOfExpectedResponse, </font><b><font color="#7f0055" size="2"><font color="#7f0055" size="2">final</font></font></b><font size="2"> </font><b><font color="#7f0055" size="2"><font color="#7f0055" size="2">int</font></font></b><font size="2"> timeout)
<div></div></font>This looks a little weird, but it allows me not to manage future and completion services in the sender.
<div> </div>
<div>John<br><br></div>
<div class="gmail_quote">2011/12/5 Steve Powell <span dir="ltr"><<a href="mailto:steve@rabbitmq.com">steve@rabbitmq.com</a>></span><br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">John,<br>Thanks for that -- I didn't understand your requirement properly.<br><br>I would tackle this by having an intermediate rpcServer which farms out the<br>
requests (acting as a client) (to your shards) -- each of which is a single rpc<br>-- and accumulates the responses for the ultimate response to the original<br>request. The original requestor makes a single request and gets back a single<br>
response.<br><br>I now see where the added flexibility requirement in the RpcClient came from.<br><br>Of course, with routing doing the 'managing the shards' bit we have a lot of<br>messages arriving back in the same reply-to queue, so someone has to do the<br>
accumulations, I can see that. However, it wouldn't be hard to rewrite the<br>rpcClient for this particular case, provided you can decide how to accumulate in<br>the face of arbitrary numbers of responses. The consumer would need to be more<br>
intelligent, but what criteria you use for deciding you've had enough replies<br>and how to 'package' them up as a single response to the original request is<br>very application-specific, I think.<br><br>I don't see a way around you having to code the accumulation explicitly, unless<br>
you know of a generally accepted multi-response scheme we should adopt?<br><br>Steve Powell (a dazed bunny)<br>
<div class="im">----------some more definitions from the SPD----------<br>avoirdupois (phr.) 'Would you like peas with that?'<br></div>distribute (v.) To denigrate an award ceremony.<br>
<div class="im">definite (phr.) 'It's hard of hearing, I think.'<br>modest (n.) The most mod.<br><br></div>
<div>
<div></div>
<div class="h5">On 5 Dec 2011, at 16:38, john doe wrote:<br>><br>> Dear Steve,<br>><br>> Actually I am dealing with a distributed database (kind of), and I am doing<br>> things like sending the same request to different shards, every shard<br>
> processes it and replies to the sender, which will merge results. It is<br>> pretty much like a map reduce job.<br>><br>> I found out that routing offers nice ways for handling this kind of<br>> request/response schemes (for example, I can send one request to one<br>
> instance of each shard of my computing grid with only one publish).<br>><br>> So I think you misunderstood my point, it is nothing like concatenating<br>> multiple response messaging, but like a more generic rpc.<br>
><br>> John<br></div></div></blockquote></div><br>