You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Carl Trieloff <cc...@redhat.com> on 2011/07/01 15:17:39 UTC
Re: QMF Questions....
On 06/30/2011 12:50 PM, Gordon Sim wrote:
> On 06/30/2011 05:36 PM, Carl Trieloff wrote:
>> On 06/30/2011 12:21 PM, Gordon Sim wrote:
>>>>
>>>> 1) Is it possible for a client to recover the "--default-queue-limit"
>>>> for a
>>>> broker?
>>>
>>> No, I'm afraid not.
>>
>> This should however be trivial to add and quite useful.
>>
>> add an R param for it to management-schema.xml, and the initialize it in
>> the construction of the queue.
>
> I think a more useful change would be to expose the current broker
> configuration.
>
> If you want to modify the schema for the queue then I think the right
> approach is to explicitly model the actual policy values in use (at
> present it is just the arguments presented when the queue was created
> that are exposed).
I think it would be better to add the defaults to the queue args on
queue construction. that way they will
a.) show up in QMF data,
b.) it is simpler and we don't have to maintain a separate model,
c.) if the queue is persisted and then restored, it will restore with
the defaults at the time of creation, and not be affected by config
changes, or broker updates
Carl.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: QMF Questions....
Posted by Gordon Sim <gs...@redhat.com>.
On 07/01/2011 03:56 PM, fadams wrote:
> I guess from a "customer" of qpid perspective I like what Carl is suggesting.
>
> The reason that I was interested in obtaining properties from the broker
> object was simply so that I could infer a property that was not explicitly
> set on the queue e.g. max size, policy etc.
>
> As it stands unless things are explicitly set in the address string or via
> queue creation in qpid-config the arguments Map for a queue is just a bit
> empty :-( I'd quite like the properties implied by broker defaults to be
> populated too.
Right, another good point on the consistency. I agree that a map of
actual queue properties would be more useful than the arguments
presented to declare. What you don't want is some place in between.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: QMF Questions....
Posted by fadams <fr...@blueyonder.co.uk>.
I guess from a "customer" of qpid perspective I like what Carl is suggesting.
The reason that I was interested in obtaining properties from the broker
object was simply so that I could infer a property that was not explicitly
set on the queue e.g. max size, policy etc.
As it stands unless things are explicitly set in the address string or via
queue creation in qpid-config the arguments Map for a queue is just a bit
empty :-( I'd quite like the properties implied by broker defaults to be
populated too.
I think Carl's argument about "if the queue is persisted and then restored,
it will restore with
the defaults at the time of creation, and not be affected by config changes,
or broker updates" is sound too. i rather think that this is *probably* what
most people would expect the behaviour to be.
That said I think it would be nice if the broker object returned the full
set of configured parameters too - from a consistency perspective it seems
logical for QMF accesors/mutators to be able to see/modify every
configurable property of a given object.
obviously this is caveated by IMHO :-)
--
View this message in context: http://apache-qpid-users.2158936.n2.nabble.com/QMF-Questions-tp6533747p6538068.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: QMF Questions....
Posted by Gordon Sim <gs...@redhat.com>.
On 07/01/2011 02:17 PM, Carl Trieloff wrote:
> On 06/30/2011 12:50 PM, Gordon Sim wrote:
>> On 06/30/2011 05:36 PM, Carl Trieloff wrote:
>>> On 06/30/2011 12:21 PM, Gordon Sim wrote:
>>>>>
>>>>> 1) Is it possible for a client to recover the "--default-queue-limit"
>>>>> for a
>>>>> broker?
>>>>
>>>> No, I'm afraid not.
>>>
>>> This should however be trivial to add and quite useful.
>>>
>>> add an R param for it to management-schema.xml, and the initialize it in
>>> the construction of the queue.
>>
>> I think a more useful change would be to expose the current broker
>> configuration.
>>
>> If you want to modify the schema for the queue then I think the right
>> approach is to explicitly model the actual policy values in use (at
>> present it is just the arguments presented when the queue was created
>> that are exposed).
>
>
> I think it would be better to add the defaults to the queue args on
> queue construction. that way they will
>
> a.) show up in QMF data,
> b.) it is simpler and we don't have to maintain a separate model,
> c.) if the queue is persisted and then restored, it will restore with
> the defaults at the time of creation, and not be affected by config
> changes, or broker updates
That is one way of doing the modelling certainly, and I wouldn't object
to it.
I think you need to be consistent about it though and have the
'arguments' essentially represent the properties of the queue. We would
then want to remove any unrecognised options (detecting those is
something I've wanted to do for sometime now anyway). We would want to
ensure that the policy recorded was the one used (and not the one
specified which is not always the same things) etc.
I agree that having a loose set of properties defined in the schema that
are then more easily evolvable is nice (of course the schema then is not
a sufficient description on it's own, but I don't have an issue with that).
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: QMF Questions....
Posted by Gordon Sim <gs...@redhat.com>.
On 07/01/2011 02:17 PM, Carl Trieloff wrote:
> On 06/30/2011 12:50 PM, Gordon Sim wrote:
>> On 06/30/2011 05:36 PM, Carl Trieloff wrote:
>>> On 06/30/2011 12:21 PM, Gordon Sim wrote:
>>>>>
>>>>> 1) Is it possible for a client to recover the "--default-queue-limit"
>>>>> for a
>>>>> broker?
>>>>
>>>> No, I'm afraid not.
>>>
>>> This should however be trivial to add and quite useful.
>>>
>>> add an R param for it to management-schema.xml, and the initialize it in
>>> the construction of the queue.
>>
>> I think a more useful change would be to expose the current broker
>> configuration.
>>
>> If you want to modify the schema for the queue then I think the right
>> approach is to explicitly model the actual policy values in use (at
>> present it is just the arguments presented when the queue was created
>> that are exposed).
>
>
> I think it would be better to add the defaults to the queue args on
> queue construction. that way they will
>
> a.) show up in QMF data,
> b.) it is simpler and we don't have to maintain a separate model,
> c.) if the queue is persisted and then restored, it will restore with
> the defaults at the time of creation, and not be affected by config
> changes, or broker updates
That is one way of doing the modelling certainly, and I wouldn't object
to it.
I think you need to be consistent about it though and have the
'arguments' essentially represent the properties of the queue. We would
then want to remove any unrecognised options (detecting those is
something I've wanted to do for sometime now anyway). We would want to
ensure that the policy recorded was the one used (and not the one
specified which is not always the same things) etc.
I agree that having a loose set of properties defined in the schema that
are then more easily evolvable is nice (of course the schema then is not
a sufficient description on it's own, but I don't have an issue with that).
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org