AMQP Management Operations

[Ted Ross <tr...@redhat.com>]

In reference to the AMQP Management Spec. v1.0 (wd02):

I see that for retrieving information about manageable objects in a 
container there are a few options:

  * Use the "READ" operation to query a specific object by name,
  * Use the "READALL" operation to query every object in the container,
  * Use the "DISCOVER-NAMES" operation to get the names of all objects
    and then "READ" to query individual objects.

I can envision situations where a given container may contain very large 
numbers of objects (possibly millions).  In this case, READALL and 
DISCOVER-NAMES will be impractical to use (i.e. they will return with 
"413 - Request entity Too Large").  Using the optional "limit" argument 
doesn't appear to help.  The thing I'm looking for may be beyond the 
limit and I'll never see it.

It would be good to have a way to query all objects of a particular 
type.  Can READALL and DISCOVER-NAMES be altered such that specific type 
names can be used, rather than only allowing "org.amqp.management"?

Thanks,

-Ted

Re: Uniqueness of names across types [was Re: AMQP Management Operations]

[Rob Godfrey <ro...@gmail.com>]

So, since I sent that mail I think we revised our thinking mostly based on
arguments about what a "type" is (if everything is derived from
org.amqp.Manageable" or something then the type restriction doesn't really
help)... though I admit to hating it myself quite a lot.  One option is to
use a path like structure for names (as one might do in a REST API), so
"/queue/foo" and "/user/foo" would be distinct... however this has the very
undesirable effect of making it virtually impossible for a user to pick a
name for the object they are creating unless they understand the scheme.
Another alternative might be to say that different management nodes should
be used for things that have distinct namespaces... so $management might
know of two other management nodes $management.queues and $management.users
and via meta data discovery you could work out where you would have to go
to manage users, and where to go to manage queues... The next OASIS call is
next week, it would be good if you could come along and we can have the
discussion with the others involved.

-- Rob

On 20 November 2014 22:10, Alan Conway <ac...@redhat.com> wrote:

> On Wed, 2013-07-31 at 10:46 +0200, Rob Godfrey wrote:
> > I've replied one technical point on the OASIS list:
> >
> > https://lists.oasis-open.org/archives/amqp/201307/msg00011.html
>
> In that message you say: " It is possible to have two objects of
> differing types with the same name (e.g. a queue named “foo” and a
> management node named “foo”)"
>
> I am pleased to hear that. I drew the opposite conclusion from 2.5.1:
>
> "A case-sensitive string identifying the entity. It MUST be unique
> within the Management Node through which it is accessed. It MAY
> change during its lifetime."
>
> "unique within the node" sounds like it has to be unique for _all_
> management entities in the node not just those of the same type.
>
> Can you clarify that for the next draft? The same goes for identity. It
> makes a big difference - I put type prefixes on the names in my impl
> which is ugly and redundant. I look forward to throwing them away.
>
> Cheers,
> Alan.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
>

Uniqueness of names across types [was Re: AMQP Management Operations]

[Alan Conway <ac...@redhat.com>]

On Wed, 2013-07-31 at 10:46 +0200, Rob Godfrey wrote:
> I've replied one technical point on the OASIS list:
> 
> https://lists.oasis-open.org/archives/amqp/201307/msg00011.html

In that message you say: " It is possible to have two objects of
differing types with the same name (e.g. a queue named “foo” and a
management node named “foo”)"

I am pleased to hear that. I drew the opposite conclusion from 2.5.1:

"A case-sensitive string identifying the entity. It MUST be unique
within the Management Node through which it is accessed. It MAY
change during its lifetime."

"unique within the node" sounds like it has to be unique for _all_
management entities in the node not just those of the same type. 

Can you clarify that for the next draft? The same goes for identity. It
makes a big difference - I put type prefixes on the names in my impl
which is ugly and redundant. I look forward to throwing them away.

Cheers,
Alan.



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

Re: AMQP Management Operations

[Rob Godfrey <ro...@gmail.com>]

I've replied one technical point on the OASIS list:

https://lists.oasis-open.org/archives/amqp/201307/msg00011.html

In general I am also in favour of being able to add restrictions to the
READALL and DISCOVER-NAMES operations such that the only bring back objects
of a given type.

-- Rob


On 30 July 2013 22:55, Ted Ross <tr...@redhat.com> wrote:

> In reference to the AMQP Management Spec. v1.0 (wd02):
>
> I see that for retrieving information about manageable objects in a
> container there are a few options:
>
>  * Use the "READ" operation to query a specific object by name,
>  * Use the "READALL" operation to query every object in the container,
>  * Use the "DISCOVER-NAMES" operation to get the names of all objects
>    and then "READ" to query individual objects.
>
> I can envision situations where a given container may contain very large
> numbers of objects (possibly millions).  In this case, READALL and
> DISCOVER-NAMES will be impractical to use (i.e. they will return with "413
> - Request entity Too Large").  Using the optional "limit" argument doesn't
> appear to help.  The thing I'm looking for may be beyond the limit and I'll
> never see it.
>
> It would be good to have a way to query all objects of a particular type.
>  Can READALL and DISCOVER-NAMES be altered such that specific type names
> can be used, rather than only allowing "org.amqp.management"?
>
> Thanks,
>
> -Ted
>
>