AMQP management spec working draft 09

Hello all,

I am relatively new to the world of the AMQP management specification. I have read the most recent draft (09) and have a couple of comments and few suggestions for clarifications that may help potential implementers.

Kind regards, Keith Wall.

1) Section 3.3.2 READ/ 3.3.3 UPDATE – Locking / Preventing lost updates

If an application using AMQP management wanted to guard against lost updates, how would it achieve it? There does not seem to be anything intrinsic to AMQP Management Spec to support it, but it looks like it could be built using its features it already possesses.

If the application wanted optimistic locking, it could define a Lockable annotation which defines some kind of (say) lockSequence attribute. The application would then be required to return the unchanged lockSequence attribute as part of the update map body. The management node would then be implemented to inspect the lockSequence and determine if the update has gone stale, rejecting with a 409 if it had. If the application wanted pessimistic locking, it could define a Lockable annotation that defines lock/unlock operations. Any thoughts? I would expect this use case to be relatively common.

2) Section 3.4.2 GET-TYPES

Is it only subtypes that are returned by this operation? If not, what value is used for (root) types that extend nothing e.g. org.ampq.queue. Is it simply an empty list?

{ “com.myapp.priority” => [“org.ampq.queue”],

“org.ampq.queue” => [] ??? }

The example in 5.10 shows a type returning itself – is this intentional?

3) Section 3.4. 2 GET-TYPES

If the optional entityType is included, what is the behaviour if entityType is unrecognised? Does an error occur or is the result an empty map? It is not clear if 3.2.2 Unsuccessful Operations should apply to this case.

Same question applies to GET-ANNOTATIONS / GET-ATTRIBUTES / GET-OPERATIONS

4) Section 3.4.3 GET-ANNOTATIONS

What if an entity type has no annotations? Is the map value an empty list or is the type omitted from the map?

Same question applies to GET-ATTRIBUTES / GET-OPERATIONS

5) Section 3.4.4 GET-ATTRIBUTES / GET-OPERATIONS

Is there a mechanism to discover the annotation(s) that own the attribute/operation? The use-case I had in mind

6) Must all attributes (and operations) be declared on an annotation?

It is not completely clear to me if attributes and operations can only be acquired through the use of annotations or whether attributes/operations can be declared on a type independently. My reading of the spec makes me think annotations are supplementary, but it ought to be explicit.

This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email.

amqp message