Many thanks - Bill On Tue, Mar 26, 2013 at 1:39 PM, Gordon Sim <[email protected]> wrote:
> 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: > [email protected].**org<[email protected]> > For additional commands, e-mail: [email protected] > >
