qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fraser Adams <fraser.ad...@blueyonder.co.uk>
Subject Re: Instrumenting the Broker
Date Fri, 11 Jan 2013 17:39:32 GMT
> Yes, with AMQP 0-10, the only time a producer indicates the destination of the message
is when it actually sends the message. The message.transfer command includes the destination
of the message, which is an exchange. A producer may send to various exchanges, simply by
changing the destination in the message.transfer command with each message. As a result, from
the broker's perspective, there's not really any way to look at a producer client and determine
which exchange(s) it's sending to.
Thanks Andy that kind of makes sense.

I think that part of the confusion might stem from some of the higher 
level APIs, I've only really used JMS and qpid::messaging (I've steered 
well clear of qpid::client as recommended by Gordon and several others 
and I know plenty of people who've been bitten by qpid::client which 
makes me glad I did :-)).

So for qpid::messaging and JMS the model tends to be that one creates a 
connection, then one creates a session and in general in qpid::messaging 
one would create Senders specifying an address and in JMS similarly one 
would create a MessageProducer. So I guess that it's fairly easy to 
*assume* that the address (which in the case of a producer could just be 
the exchange name for something like amq.match) is associated with the 

if you normally do:

Session session = connection.createSession();
Sender sender = session.createSender("amq.match");


it's easy to fall into that trap.

I guess that the alternate send which actually takes an address (e.g. 
the JMS MessageProducer |*send 

<http://docs.oracle.com/javaee/5/api/javax/jms/Destination.html> destination, 
<http://docs.oracle.com/javaee/5/api/javax/jms/Message.html> message)| ) 
is a closer analogue to the underlying AMQP message.transfer I guess 
that the higher level abstraction just acts as a cache for the real AMQP 

Thanks again Andy I think that your explanation has helped clarify in my 
mind the transient association between Connection and Exchange even 
though I suspect in practice the vast majority of producer code is 
likely to be written in a way that retains what looks like a more 
sustained association, but that's only in the client runtime not in the 


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