qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fraser Adams <fraser.ad...@blueyonder.co.uk>
Subject The future of Qpid Management.
Date Sun, 23 Feb 2014 17:04:19 GMT
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: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org


Mime
View raw message