qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: Questions from a novice
Date Tue, 26 Mar 2013 17:39:05 GMT
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
For additional commands, e-mail: users-help@qpid.apache.org


Mime
View raw message