On 07/12/2012 08:01 AM, Rogier Boon wrote:
Hello List,
I have heaps of trouble routing my messages and to be honest I don't have a
clue what I'm supposed to do.
So here is my situation:
I have a server A and a client B. The client sends commands to the server using
a message, the server replies with a message using the replyTo-information.
I'm using the request reply construction from the examples in the
documentation. That is the client creates a temporary queue with a unique name
with the
sole purpose of recieving replies.
This scenario works when I use a single message broker.
The next step is to split this situation between hosts (Host A for the server
and Host B for the client). Each host is running a messagebroker.
Using a static queue route I can get the commands from the client to the server.
However the replies, intended for the temporary queue obviously fail. I assumed
I could make a dynamic route on an exchange from A to B and then bind the local
queues to this exchange. However, it doesn't seem to work.
I'm searching for an example for this situation or a pointer to documentation
that can help me solve my problem.
If you use a unique 'topic' subject (i.e. a unique routing key with a
given exchange) as the reply-to address instead of a response queue
name, then it is easier to federate the solution dynamically.
Attached is a patch to apply to the client.cpp example bundled with the
c++ messaging client (you didn't mention which language your application
is written in, but this should be translatable to the others).
To get a simple federated example, start two brokers A and B.
Then compile and run the server.cpp example against broker B. This
creates a queue named 'service_queue' for requests (you could of course
rely on that queue being already created or have a requests topic or
whatever).
Now create a queue on broker A for the client to send requests to - in
this simple example we'll keep the name the same as that is what the
example expects. So e.g. qpid-config add queue service_queue.
Now setup federation. First we need to ensure that requests sent to A
get to broker B, and thus to the server application:
qpid-route add queue <broker-B> <broker-A> '' service_queue
Then we need to ensure that all responses get back to the clients that
are connected to A:
qpid-route dynamic add <broker-A> <broker-B> amq.direct
(The use of amq.direct is arbitrary, and just chosen because it exists
by default on all brokers so saves having to create one).
Now you can apply the attached patch to the client.cpp example, compile
it and run it. You can run as many concurrent instances as you want and
can run them against either A or B, and they should get their responses
back correctly.
The use of a Uuid as the subject name in the modified client code is
simply a way of ensuring unique 'addresses' for each client. You could
use some other scheme if desired.
Does this help?
Index: examples/messaging/client.cpp
===================================================================
--- examples/messaging/client.cpp (revision 1359830)
+++ examples/messaging/client.cpp (working copy)
@@ -48,8 +48,9 @@
Sender sender = session.createSender("service_queue");
//create temp queue & receiver...
- Address responseQueue("#response-queue; {create:always, delete:always}");
- Receiver receiver = session.createReceiver(responseQueue);
+ std::stringstream replies;
+ replies << "amq.direct/" << qpid::types::Uuid(true) << "; {node: {type:topic}}";
+ Receiver receiver = session.createReceiver(replies.str());
// Now send some messages ...
string s[] = {
@@ -60,7 +61,7 @@
};
Message request;
- request.setReplyTo(responseQueue);
+ request.setReplyTo(replies.str());
for (int i=0; i<4; i++) {
request.setContent(s[i]);
sender.send(request);
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
