[rabbitmq-discuss] using client from different threads

[john doe]

>
> 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.
>
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).

Typically, you'll have numberOfExpectedResponse=bodies.size() *
numberOfShards;
*

public* List<*byte*[]> rpcCall(*final* String messageId, *final* String
exchange, final String routingKey, *final* List<byte[]> bodies, *final* *int
* numberOfExpectedResponse, *final* *int* timeout)
This looks a little weird, but it allows me not to manage future and
completion services in the sender.

John

2011/12/5 Steve Powell <steve at rabbitmq.com>

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20111205/5f6bf8f7/attachment.htm>