On 23 February 2014 18:04, Fraser Adams <[email protected]>wrote:
> Hi All,
> The Java Broker has recently (QPID-5555) added some changes to
> Lifetime/Exclusivity policies based on the comments:
>
> "AMQP 0-8/9/9-1 and AMQP 0-10 both have notions of "autodelete" and
> "exclusive" for Queues. However while they use the same names, they are in
> fact subtly different. The Java Broker Queue implementation should better
> abstract these notions into the lifetime and exclusivity policies."
>
>
> I was updating a few things as a result of this and it got me thinking
> that another discussion on the future of Qpid Management was somewhat
> overdue.
>
>
> At face value there's no great issue with these changes when viewed only
> in the context of the Java Broker, but when viewed more widely we note that
> in QMF for the C++ broker autoDelete and exclusive are both boolean values.
>
>
>
On the autodelete and exclusive cases... the issue is/was that while 0-9
and 0-10 both had these boolean attributes, they meant quite different
things... The Java Broker was trying to implement both and was tieing
itself in knots because it was trying to represent the differing states in
booleans. Ultimately I think it is better to model the actual states /
policies and then choose how we represent them to the end users.
> Obviously the Management Models of the C++ and Java Brokers have diverged
> somewhat over time as indeed have the capabilities of the two brokers -
> particularly with respect to Queue capabilities/types but also recently
> with the addition of things like
> Incoming/Outgoing/Domain/Topic/QueuePolicy/TopicPolicy
> to the C++ Broker and I guess QPID-5504 (Allow other routing/storage node
> types than Queues and Exchanges) is likely somewhat related.
>
> So the real question is what's the best approach on this going forward?
> Hopefully the aim for both Brokers will be to converge on using AMQP 1.0
> Management as the Management *protocol*, but that's ultimately just a
> mechanism for retrieving the management information with a consistent
> *syntax*, the problem is that the divergent Management Models means that
> there is different *semantics* between the two Brokers, which is a little
> less easy to address.
>
>
Agreed - I would like us to use the opportunity of AMQP Management to
define a common vocabulary for the same semantics and make it easier to
decompose the different aspects of these semantics so not every Queue might
implement the same set of policies, they do use the same name for the same
semantics (and can aspire to potentially implementing all semantics in
time.)
> The good news is that there is a significant amount of overlap and the QMF
> plugin for the Java Broker that I put together covers a decent number of
> the core use cases, but each Broker does offer some additional
> capabilities. Probably the most *awkward" from the point of view of a
> "converged" approach is the Java Broker Virtual Host capability, but even
> fairly small things like the Lifetime/Exclusivity stuff here and say the
> ability of the Java Broker to support multiple different Ports (the C++
> Broker Port is just the bound AMQP Port on a TCP transport) make things a
> little fiddly. No standard way in AMQP to specify things like queue
> max-size, max-messages etc. doesn't help either I guess :-(
>
>
Things like the max queue size / message size, etc... are definitely things
that we should standardize within Qpid (using AMQP management) and then
push for the wider world to adopt the same standard.
>
> Perhaps the *right* answer is that convergence is a futile exercise?? I
> guess that with AMQP 1.0 Management different vendors can implement
> whatever semantics they like, so why should the Qpid C++ and Java Brokers
> have any real need to be consistent other than because they are both badged
> "Qpid"? I guess the main reason is that being different could easily
> confuse users. I know it confuses me and I'm fairly familiar with this
> stuff, I usually wind up looking through code - so best of luck to any
> n00bies.....
>
>
> It would be really nice to be able to put together some tooling that is
> reasonably agnostic of some of the differences. I think that's possible to
> an extent but there are some really awkward areas such as how one
> represents relationships between Management Objects - in QMF we have
> references e.g queueRef and exchangeRef in Binding but AMQP 1.0 Management
> is pretty quiet on how (or indeed whether) this stuff should be
> represented. There now seems to be some introspection mechanism in AMQP 1.0
> Management which is good, but as I say the relationship stuff is important
> semantically. Similarly neither QMF nor AMQP 1.0 Management provide a way
> to introspect Method formal parameters. So you can get hold of the
> available Method names for sure, but arguments/parameters?? This is a real
> pain - the number of times I've had to work my way through Broker code to
> work out how on earth I actually call a method!!! Having a mechanism to
> introspect arguments and their types means that it becomes feasible to
> create tooling that can be useful across different vendors' products
> without it everything needs to be a bit bespoke.
>
>
> Even if convergence does end up being somewhat futile there are
> non-trivial issues to consider when moving to AMQP 1.0 Management, for
> example how does one migrate existing QMF based tooling (do we have
> parallel tool sets or parallel back ends - the latter might be a better
> migration approach as it doesn't pull the rug from users, but I don't
> know). For the Java Broker it might be even harder with a fairly
> comprehensive, but embedded GUI. Is the intention to retain that and only
> expose a limited set of information via AMQP 1.0 Management?
>
>
I'm expecting that the embedded UI (which is really just a front end onto
the REST API) and the AMQP management will be kept pretty much in step.
Eventually I'd like to see the embedded UI use AMQP management where it is
available, and just fall back to the REST API where it is not. The changes
I am making currently are really to enable the REST API and AMQP management
to work off the same meta-data inside the broker.
>
> I realise that this isn't the first time I've got on my soap-box a bit
> with respect to Management, but given that the AMQP 1.0 Management
> specification is starting to become a bit more "kickable" I think that it's
> probably a good time for the community to have a decent discussion on this.
> I think that we *really* need to have a good community discussion before
> AMQP 1.0 Management becomes completely set in stone, unfortunately so far
> I've not seen an awful lot of discussion about it.
>
>
>
Agreed - with the work in the Java Broker and, I believe, in Dispatch, it
would be good if we as the Qpid community could start to come up with what
we believe are the common entities and operations we will be supporting.
I'm not sure what current plans - if any - there are for the C++ broker to
support AMQP management.
>
> Another more specific question relates to the LifetimePolicy which is:
>
> public enum LifetimePolicy
> {
> PERMANENT,
> DELETE_ON_CONNECTION_CLOSE,
> DELETE_ON_SESSION_END,
> DELETE_ON_NO_OUTBOUND_LINKS,
> DELETE_ON_NO_LINKS,
> IN_USE
> }
>
> Whereas in the AMQP 1.0 specification I note:
>
> The following standard lifetime-policies are defined below:
> delete-on-close,
> delete-on-no-links,
> delete-on-no-messages
> delete-on-no-links-or-messages
>
> Is there a reason for the enumeration to be quite so different, is that to
> do with the AMQP 0-8/9/9-1 stuff?
>
So, the lifetime policy in the Java Broker is supposed to be generic to all
objects (not just queues)... it also - as you say - is designed to support
0-9 (and 0-10) models...
In terms of the specific enumeration in the 1-0 spec ... those are
specifically for dynamically created nodes where "permanent" would not be
something one should be supporting (the dynamic node use case is really
temporary queues).
In terms of the other cases, IIRC 0-9 needs delete on connection close,
0-10 needs delete on session termination. Since 0-x don't really support
the concept of "inbound" links where it has auto-delete policies they tend
to be in terms of "outbound" links. My mental model for a queue is that
bindings from an exchange to a queue are actually links (inbound from the
queues point of view) and thus a 0-x queue autodelete policy is in terms of
"no-outbound-links". "IN_USE" was the best synonym I could think of for
"no links or messages" for things that might not actually hold messages
(remembering that in the Java Broker these policies apply to all objects).
Basically "IN_USE" is supposed to signify that it will only be deleted
when nothing else refers to it (which for queues is the same as
"no-links-or-messages").
Hope this helps,
Rob
>
> Regards,
> Frase
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
