qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lance D." <lan...@gmail.com>
Subject Re: Instrumenting the Broker
Date Fri, 11 Jan 2013 22:36:44 GMT
I love this discussion.  It's actually very helpful in getting a better
grasp of where QPID fits into the bigger picture of the AMQP world.

I'm going to inject a little more philosophical question into the nuance
here.  I completely get what Andy said about the standard and it makes
sense.  However, what frustrates me is that, as the API is implemented in
QPID, internally QPID has access to exactly what I want, it was just
overlooked or ignored when it comes to storing that detail.  I say that
because my tools can capture the connection events and collect enough
detail that later I can see what publisher sent the message.  However, in
order for that to work, my tools must be running before anyone connects;
that is less useful for use debugging a large system of systems.

Aside from the standard's details that allow a connection to send to any
queue, is there are reason that QPID doesn't keep some sort of mapping that
maintains what was declared at connection time and/or the most recent

Thanks and happy weekend folks!

On Fri, Jan 11, 2013 at 12:39 PM, Fraser Adams <
fraser.adams@blueyonder.co.uk> wrote:

> 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
> Connection/Session.
> if you normally do:
> connection.open();
> Session session = connection.createSession();
> Sender sender = session.createSender("amq.**match");
> ........
> sender.send(message);
> .........
> 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/**MessageProducer.html#send%**
> 28javax.jms.Destination,%**20javax.jms.Message%29<http://docs.oracle.com/javaee/5/api/javax/jms/MessageProducer.html#send%28javax.jms.Destination,%20javax.jms.Message%29>
> >*(**Destination <http://docs.oracle.com/**javaee/5/api/javax/jms/**
> Destination.html<http://docs.oracle.com/javaee/5/api/javax/jms/Destination.html>>
> destination, Message <http://docs.oracle.com/**javaee/5/api/javax/jms/**
> Message.html <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 destinations.
> 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 broker.
> Frase.

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