activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gaurav Sharma <gaurav.cs.sha...@gmail.com>
Subject Re: Implementing Request Response mechanism
Date Tue, 21 Aug 2012 18:18:16 GMT
So, instead of having N brokers (1 per consumer), why not have N
destinations (1 per consumer)? If possible, further simplify it to less
than N destinations if you can shard/group your messages (don't know your
domain) and just use message properties and selectors to filter them at the
time of retrieval from destinations. It achieves the same effect with a
much simpler and maintainable system.

On Mon, Aug 20, 2012 at 5:17 PM, zackhasit <zackhasit@gmail.com> wrote:

> >>So, that request-response recipe uses temporary destinations to route
> messages. Your use-case is that of request-throttling and load-balancing
> the
> 'service'.
>
> Not really. There is no service but a transport queue which could be IPC
> for
> that matter. I may not have explained it well but I have the client which
> sends the request to server and server has to respond to same client after
> processing the message but onto his remote broker. Here only difference is
> that each have their own brokers for receiving but they send to remote
> broker. I have attached a picture to make it clear. Please let me know if
> it
> makes sense. http://activemq.2283324.n4.nabble.com/file/n4655342/temp.PNG
> temp.PNG
> Converting the temporary queue to non temporary one is trivial I think
> (using right method really). Note that I have no requirement to use HTTP or
> have a "service" . I am trying to do what I have in Diagram with request
> response model. Just figuring out how to do it. The reason for using Active
> MQ is the features such as persistence which could be used in future.
>
>
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/Implementing-Request-Response-mechanism-tp4655304p4655342.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message