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 <zackha...@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. >
