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 Re: Comments on the AMQP management spec
Date Fri, 11 Apr 2014 08:35:54 GMT
Hi Justin & Rob
I've replied to this on the TC comment list, but for completeness and 
transparency here's what I said:


# 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 

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:
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 
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.


On 11/04/14 00:07, Rob Godfrey wrote:
> Hi Justin,
> can you send these comments to the public TC comment list (see [1]) so they
> can be incorporated in the discussions there on any updates to the spec (in
> your case -  since you are employed by an organisation who is a member of
> OASIS and have voting members on the TC - this may not be strictly
> required... however it seems like good form :-) ).
> I'll try to respond on the technical points (later) in the morning.
> -- Rob
> [1] https://www.oasis-open.org/committees/comments/index.php?wg_abbrev=amqp
> On 11 April 2014 00:20, Justin Ross <jross@apache.org> wrote:
>> Hi, everyone.  I've been using the draft management spec to develop some
>> command line tools[1], and I've got some questions and comments.  These
>> comments are based on working draft 8 of the spec[2].
>> Thanks,
>> Justin
>> [1] https://github.com/ssorj/bailey (Watch out! It's a work in progress.)
>> [2]
>> https://www.oasis-open.org/committees/document.php?document_id=52425&wg_abbrev=amqp
>> ---
>> # Use of AMQP application-properties
>> Given that values in AMQP 1.0 application properties cannot be lists or
>> maps (yikes--I didn't know that), I feel it's inadvisable to use
>> application properties to define requests.  We'd be better off using
>> properties in the message body.  Otherwise, we'll have to define standard
>> string encodings in every instance where we want to use a non-scalar type.
>> # 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.
>> # QUERY and pagination
>> There doesn't appear to be a way to query for the total count without
>> fetching all the values.  Without that, you can't build a data efficient
>> page-navigation UI that offers links to each page (or just the last page).
>> Requests using offset and count should perhaps instead use offset and
>> "limit".  That's more familiar to those who have used SQL, and it correctly
>> signals that the number returned may be less than the number requested.  In
>> my view, the request should use "limit", and the response should use
>> "count".
>> Also, if we're doing paging we need to do sorting as well.  Otherwise, A
>> client UI cannot build a sortable paginated table without pulling down
>> everything.
>> # Request-response
>> There's a note in section 4 that multiple response messages may be produced
>> for a single request.  How should a client determine whether the response
>> is complete?
>> The text says the response message must contain "a list of addresses of
>> other Management Nodes".  Perhaps this should more explicitly prohibit
>> listing the currently-in-communication management node (or drop the word
>> "other").
>> What is the intended use of this?  That is, what new behavior do you get
>> when something is registered?
>> # Ping
>> I'd like to see a standard PING or ECHO operation on $management.  I can
>> simulate it by using an arbitrary operation, but that seems less than
>> straightforward for implementors.
>> # Clerical stuff
>> Awkward phrasing: "so if any of the changes cannot be applied,
>> the
>> entire operation should not be applied and to multiple values changed this
>> MUST result in a failure response"
>> 3.4.1: Typo: "this operation supports pagination <though> which a request"
>> 3.4.1: Awkward phrasing: "A result set of size N <can be considered to
>> containing elements>"
>> # Odds and ends
>>   - 2.3: Should this reference the AMQP definition of a "node"?
>>   - 3.1: It would be nice to mention that locales is a comma-separated list.
>>   The RFC mentions it, but you have to dig down a bit.
>>   - What is a good example of a generic value made specific in an
>> UPDATE response?
>>   - 3.3.3: Is the lack of attribute append a problem?  Right now, there is
>> only replacing list values, and dueling actors could mean lost state.

To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

View raw message