On 26 March 2013 17:39, Gordon Sim <g...@redhat.com> 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 JMX interface actually uses two ports (one for an RMI Registry to advertise the JMX ConnectorServer which is on the other). The HTTP manamegent is indeed on its own port (for now at least). It is possible to prevent them being used at all if that is necessary (though obviously at the expense of being able to manage them by those ports/interfaces, though a local JConsole etc injected attachment to the JVM is always possible regardless to achieve JMX access). An initial cut of a QMF2 plugin for the Java broker is in progress / exists as of last week, and that would use the AMQP port for associated management traffic.
> > 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-unsubscribe@qpid.apache.**org<users-unsubscr...@qpid.apache.org> > For additional commands, e-mail: users-h...@qpid.apache.org > >
