qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Freeman <ke1g...@gmail.com>
Subject Questions from a novice
Date Tue, 26 Mar 2013 16:12:50 GMT
Please pardon me if my questions are all clearly answered in the
documentation.  I've been reading for a while, and am still in doubt.

While I have done C++ and Java programming in the past, I have a lot more
experience in C, and I've mostly been a Python programmer of late.  So also
please excuse any inappropriate Pythonisms.

Let me start with what I think I know, in hopes that folks will disabuse me
of my misconceptions.

Queues and exchanges are manifestations implemented within the broker
process, and do not have separate existence (counting disk files storing a
queue's messages, when required, as only manipulated by and belonging to
the broker).  For example, when you fetch a message from a queue, you are
actually talking to the broker.

Qpid brokers speak AMQP on the wire.  Excluding command line arguments,
config files, stuff in the data directory, and possibly *nix signals,
brokers don't communicate in any way but AMQP.  Specifically, there is no
separate port, and no recognizably non-AMQP communication with the main
port, used for configuration, control, and monitoring.

The AMQP standard does not address configuration, live re-configuration,
control, or monitoring.  QMF is a Qpid specific separate protocol designed
to address live re-configuration, control, and monitoring.

QMF is currently, but not necessarily continuing to be, specific to the C++

QMF is carried over regular AMQP messages, directed to particular addresses
that know to interpret the body as QMF, or in specific queues which QMF
consoles/clients own or to which they subscribe, knowing that they should
interpret the messages as QMF.

QMF v2 is current, though many deployed brokers might only support v1.
Some deployed brokers may not support QMF at all (configured completely
through configuration files?).  A major difference between v1 and v2 is
address structure.

Tools like qpid-config are using QMF to do what they do.

Now some specific questions:

1.  Within a single broker, object IDs are guaranteed unique, but are not
guaranteed unique across multiple brokers.  If all brokers in question are
part of a federation, do they magically arrange for object ID uniqueness or

2. To control/monitor a federation, need a  QMF console connect to each
broker, or can it connect to one and have the QMF messages pass over the
federation links and routes?

3. Might queue name also be assured to be unique within a broker?  If so,
is that because the broker enforces it, or because the creation of multiple
queues with the same name would lead to a non-working configuration (that
might still need to be managed in order to be fixed)?

4. If necessary, I'm thinking of disambiguating object IDs across browsers
by decorating (the string representing) the object ID with (a string
representing) the broker IP address and port.  Is there something easier
and/or better?  Specifically, if all relevant brokers are in the same
federation, are the labels used in setting up routes guaranteed to be
stable and unique (within the federation), making it possible for object
labels to survive re-hosting of a broker?

5. Is it possible for a broker to be a member or more than one independent
federation, or does connection via this single broker define all brokers as
being part of one large federation?

6. Is the concept of "class" and "package" in QMF object filtering related
to implementation classes and namespaces on the broker?  If so, will this
filtering find sub-classes, or must the description be instance exact?

I'm sure that I have more questions, but I don't know about them yet.

Thanks in advance,

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