If your only concern on the client side is to not pile up messages then
why don´t you simply use a topic for the reply?
Give each client his own topic on the broker by the servers. If there is
no client listening on the topic then the message can be simply discarded.
This has the advantage that you do not need one broker per client.
Btw. for a real time application you could also check if an event
oriented architecture may also help you. In that case the server sends
changes to topics and clients can simply listen if they are interested.
Christian
Am 21.08.2012 02:17, schrieb zackhasit:
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.
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
