On 03/26/2013 04:12 PM, Bill Freeman wrote:
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.
That is true of the c++ broker, but the Java broker has supported RMI based JMX management that did use a separate port. It now offers an HTTP based management (not sure if that is via a separate port?).
The AMQP standard does not address configuration, live re-configuration, control, or monitoring.
Not yet. There are plans to expand the standard to cover these aspects however. I would love to see people on this list play a big part in that by discussing the things we all individually and collectively want in this area. Between us all we have quite a lot of experiences (good and bad!) to bring to bear on future work.
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++ broker. 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.
The biggest change was the encoding of the content of messages. QMFv2 moved to encoding messages as AMQP 0-10 maps where previously QMFv1 used the basic type encoding of AMQP 0-10 but in a manner that required specific knowledge of how each different sort of message was encoded (which made handling QMF messages more complicated).
There were some 'addressing' changes also.
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 not?
They do not.
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?
In general, at present it needs to connect to each broker. It would be possible I think to configure federation in order to allow messages to be relayed through one single broker, but that wouldn't work in any transparent or seamless way. (I think that is one of the weaknesses of the current solution that I would want to see addressed in progressing work on a standardised scheme).
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)?
Queue names are indeed enforced to be unique within a given broker (but not between brokers in a federation).
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?
The brokers 'tag' in a federation is stored persistently (but can also be set via command line option). Assuming this is what you mean by label, then yes, the intention is that it survives restart.
(Object ids are another area I would personally like to see significantly improved in any AMQP based new management protocol).
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?
There isn't really a concrete concept of 'a federation'. (Bad naming on my part again!). All there is really is connections between brokers.
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?
No, the class and package don't tie to the code that implements e.g. Queue or Exchange. QMF doesn't have any notion of subtyping as far as I'm aware.
--------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
