Justin's Comments on the AMQP management spec

[Fraser Adams <fraser.adams@blueyonder.co.uk>]

Hi all,
I tried to send this as a direct reply to Justin's post to him and this 
list, but my first (and second) attempts appeared to get bounced (Rob 
Godfrey PMd me to say he hadn't seen it). Hopefully this attempt will 
arrive.

Fraser

RE:

# Application properties and studlyCaps

The spec calls for studlyCaps for standard property names, whereas an 
earlier draft had hyphenated names. FWIW, I prefer the latter, since 
it’s in line with the core AMQP spec.


hyphens are an interesting case as I've found to my cost . You might 
have seen my post to the qpid user list back in February entitled "A 
write up of some AMQP 1.0 Experiments" during those experiments I 
discovered some interesting behaviours with hyphenated names and message 
selectors:

In precis whilst hyphens are indeed legal AMQP 1.0 the *are not* legal 
wrt. JMS message selectors, indeed they are not *actually* legal JMS 
application property names (I only realised that myself when I was 
trying to figure out the selector thing). It turns out that JMS 
properties have to have names that are valid Java identifiers.

Now technically that might be a moot point from the perspective of an 
AMQP Specification - after all if it's legal AMQP.... but there's no 
point making things hard for Java clients and it also doesn't seem great 
to have one AMQP Specification specifying a form of properties that 
would be illegal somewhere else:
https://svn.apache.org/repos/asf/qpid/trunk/qpid/specs/apache-filters.xml#section-legacy-amqp
Explaining the reason for the choice might be worthwhile though.


On a related note previous working drafts of AMQP 1.0 Management had 
specified using lists as message bodies in quite a few places, which is 
perfectly legal AMQP (though as you have noted lists and maps as 
property values is not) but because lists are a pain for JMS I argued 
that was *probably* a bad idea. I think that you do more python things 
than Java don't you? For python, C++ and pretty much everything else 
lists are fine, but for Java aaaarrrgggg!!

Re: # Ping
That's an interesting one, something like that would be useful, but I 
personally don't think a simple ping to a $management node scales, so 
that would be a very restrictive solution in a large topology of 
containers or where there are lots of clients. I included the following 
in an email to Rob but it was quite a long exchange and it may have been 
a bit TL;DR :-) but here goes.....

One other thing that I keep forgetting to mention; in QMF2 Agents 
broadcast heartbeat messages periodically to a topic so clients can 
identify if Agents have gone away. I guess that this is perhaps more 
useful in QMF2 where Agents aren't *necessarily* co-located with the 
Broker, but it has got me thinking. In AMQP 1.0 Management I guess that 
the $management node is likely to be pretty coupled to the Container's 
lifecycle such that a client could probably infer that the $management 
node is gone based on interception of a connection failure (e.g. via 
something like a Connection Exception Listener) but a couple of use 
cases fall out of that sort of scope:
1) What about Management nodes other than $management? It's possible 
that the Container and $management might be available, but some other 
Management node a user is interested in might possibly die 
asynchronously for whatever reason (a simple use case might be one 
client DEREGISTERing a Management Node that another client happens to be 
using).
2) What about Message-oriented (as opposed to Connection-oriented) APIs 
such as Messenger, with those the fact of Connection closing wouldn't 
necessarily register until the next time a request was made.

Clearly a Management client could figure this out by some sort of 
polling - and that might be better than needing a topic to broadcast a 
heartbeat (though it doesn't scale as well if there are lots of clients) 
but if polling is the expected way to accomplish this then I'd say that 
the Management Specification needs to specify a standard Management node 
operation to achieve this (perhaps STATUS ?). For someone designing a 
decoupled client (say a WebApp) being able to determine the status of 
Management nodes and provide feedback to the user is pretty useful.

Regards,
Frase