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++ 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. 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? 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, Bill
