qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Freeman <ke1g...@gmail.com>
Subject Re: Questions from a novice
Date Tue, 26 Mar 2013 17:44:21 GMT
Many thanks - Bill

On Tue, Mar 26, 2013 at 1:39 PM, Gordon Sim <gsim@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 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-unsubscribe@qpid.apache.org>
> For additional commands, e-mail: users-help@qpid.apache.org
>
>

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