[rabbitmq-discuss] using client from different threads

[Steve Powell]

John,
Thanks for that -- I didn't understand your requirement properly.

I would tackle this by having an intermediate rpcServer which farms out the
requests (acting as a client) (to your shards) -- each of which is a single rpc
-- and accumulates the responses for the ultimate response to the original
request.  The original requestor makes a single request and gets back a single
response.

I now see where the added flexibility requirement in the RpcClient came from.

Of course, with routing doing the 'managing the shards' bit we have a lot of
messages arriving back in the same reply-to queue, so someone has to do the
accumulations, I can see that.  However, it wouldn't be hard to rewrite the
rpcClient for this particular case, provided you can decide how to accumulate in
the face of arbitrary numbers of responses.  The consumer would need to be more
intelligent, but what criteria you use for deciding you've had enough replies
and how to 'package' them up as a single response to the original request is
very application-specific, I think.

I don't see a way around you having to code the accumulation explicitly, unless
you know of a generally accepted multi-response scheme we should adopt?

Steve Powell  (a dazed bunny)
----------some more definitions from the SPD----------
avoirdupois (phr.) 'Would you like peas with that?'
distribute (v.) To denigrate an award ceremony.
definite (phr.) 'It's hard of hearing, I think.'
modest (n.) The most mod.

On 5 Dec 2011, at 16:38, john doe wrote:
> 
> Dear Steve,
>  
> Actually I am dealing with a distributed database (kind of), and I am doing
> things like sending the same request to different shards, every shard
> processes it and replies to the sender, which will merge results. It is
> pretty much like a map reduce job.
>  
> I found out that routing offers nice ways for handling this kind of
> request/response schemes (for example, I can send one request to one
> instance of each shard of my computing grid with only one publish).
>  
> So I think you misunderstood my point, it is nothing like concatenating
> multiple response messaging, but like a more generic rpc.
>  
> John