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.
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.
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 :-(
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 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.
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?
Regards,
Frase
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
