On 04/05/2012 08:57 AM, Fraser Adams wrote:
Hi All,
Most of the properties for most of the Management Objects are fairly
self-explanatory, but there are a few that leave me scratching my head
so I'd appreciate some info:
Broker:
stagingThreshold (description says Broker stages messages over this size
to disk, but what does this really mean and what happens if no
persistence store is specified?)
That 'feature' is no longer supported. The property should be removed or
deprecated in some way.
Also on Broker why is there a specific "connect" method when other
objects are created using the "create" method? that seems slightly
inconsistent, is there a reason or is it just one of those
historic/evolutionary development things - I know "create" really only
started to become useful from version 0.10
Yes, its just the evolution of the schema. The connect() pre-dates the
create() however there was a patch up for review recently that unifies
this so hopefully it will be aligned in the not too distant future.
Agent:
Although the properties have descriptions it's not clear to me what they
actually relate to, for example what is a "systemId" and how would one
use it? what are broker/agent Banks?
I *think* this was part of the original QMF. Ted can probably clarify or
correct.
Subscription:
name - well obviously it's the name, but I can't see any mechanism for
setting this, in JMS it seems to simply be a number, is there actually a
point to this property?
AMQP subscriptions have names. The client libraries usually pick a
unique name on the applications behalf. It is a useful property though
not always directly settable from the application.
acknowledged - this is a property not a statistic and seems to get set
on creation, but what's an acknowledged subscription? Is this related to
reliable versus unreliable links so for example if I was to check this
on a default federated connection acknowledged would be set false?
Yes, that is correct. It indicates whether messages are expected to be
acknowledged by the client.
creditMode - what do WINDOW and CREDIT mean, I've no idea how these
would be set (in JMS or qpid::messaging at least)
Again, this is an AMQP level setting.
arguments - what arguments would relate to a Subscription? As far as I
was aware Subscriptions are created "under the hood" when consumer
destinations are created and are associated with the queues so I'm
curious about the arguments (I understand Queue arguments and Binding
arguments just not Subscription arguments).
Arguments is just a catch all for any extension properties on a
subscription.
Connection:
incoming - leaves me baffled, surely all connections to a broker are
incoming??
No, a connection can be established from this broker to another. I.e.
this is a (perhaps clumsy) way of describing who initiated the connection.
userProxyAuth - what circumstances would cause this to be set?
This is set on connections that are allowed to send messages on behalf
of another user, i.e. the userid check on messages will be suppressed.
It is used primarily for federation links at present.
remoteProcessName - this is quite useful, unfortunately though Java
Clients just say "Qpid Java Client" which is fair enough as that's the
process name, is there a way to set a different value on a Java Client
as it would be quite useful to be able to see this from the connection.
I don't think so, but I agree it would great if you could as its a very
useful property.
shadow - what's a shadow connection? Is it something to do with clustering?
Yes. Shadow connections in the current cluster are the clones of
connection state on the nodes in the cluster other than the node with
the actual connection.
Session:
name - as with Subscription is there any point to this, it seems to be a
UUID but I can't see what it would be used for, the connectionRef is
more useful.
Again at the AMQP level every session has a name so its somewhat useful
to track. Some clients let you set this; otherwise you get a unique name
assigned for you (usually a uuid).
detachedLifespan/attached - so what to attached/detached mean in the
context of Session.
AMQP 0-10 allows a session to be reattached. However this is not
implemented so the properties are likely redundant at present.
framesOutstanding and clientCredit at face value would seem useful but
how would I use them for diagnosing problems?
The clientCredit is no longer used (it was part of a now abandoned flow
control scheme). I don't know what framesOutstanding is supposed to be
for. Its been around for a very long time but doesn't seem to be used at
present. Ted, any recollection of this?
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
