Page History

systemRef

objId

System ID

Y

port

uint16

TCP Port for AMQP Service

Y

A broker may be listening on more than one port - I suggest that we want to have a new entity to represent listening ports/transports

workerThreads

uint16

Thread pool size

Y

maxConns

uint16

Maximum allowed connections

N

Java broker currently doesn't support a connection limit

connBacklog

uint16

Connection backlog limit for listening socket

N

What is this? It "defines the maximum length to which the queue of pending connections for sockfd may grow (from man page for the listen() system call"

stagingThreshold

uint32

stagingThreshold

uint32

Broker stages messages over this size to disk

N

Java Broker does not currently support stagingThe 'staging' functionality is poorly conceived on the c++ broker and needs reviewed; it is really just about handling very large messages by not requiring that the full contents ever be held in memory

mgmtPubInterval

uint16

Interval for management broadcasts

Y

version

sstr

Running software version

Y

dataDir

sstr

Persistent configuration storage location

Y

Java Broker currently displays the value of $QPID_HOME here

( uint32 sequence, lstr body ) echo ( uint32 sequence, lstr body)

Request a response to test the path to the management broker

Y

void connect ( sstr host, uint32 port, bool durable, sstr authMechanism, sstr username, sstr password, sstr transport)

Establish a connection to another broker

Y

Doesn't allow a vhost to be specified, nor is transport defined (is ssl a transport?) yes, ssl would be a transport as would e.g. rdma. Perhaps a URL would be simpler?

void queueMoveMessages ( sstr srcQueue, sstr destQueue, uint32 qty)

Move messages from one queue to another

N

Queues are local to vhosts, not brokers... since you may have queues with the same name on two separate vhosts on the same broker - this method cannot be implemented on a broker which supports multiple vhosts. Should also add an arguments map to allow filters to be applied

msgTotalEnqueues

count64

Total messages enqueued

Y

msgTotalDequeues

count64

Total messages dequeued

Y

msgTxnEnqueues

count64

Transactional messages enqueued

msgTxnDequeues

count64

Transactional messages dequeued

msgPersistEnqueues

count64

Persistent messages enqueued

Y

msgPersistDequeues

count64

Persistent messages dequeued

Y

msgDepth

count32

Current size of queue in messages

Y

Is this with or without unacked messages (i.e. does it include all messages for which the dequeue has not yet been committed)?)?It includes unacked messages
Also would seem to make sense to provide high watermark for queue depth (bytes and msg)GS: +1 on high watermark for queue depth; would be very useful

byteDepth

count32

Current size of queue in bytes

Y

byteTotalEnqueues

count64

Total messages enqueued

Y

byteTotalDequeues

count64

Total messages dequeued

Y

byteTxnEnqueues

count64

Transactional messages enqueued

byteTxnDequeues

count64

Transactional messages dequeued

bytePersistEnqueues

count64

Persistent messages enqueued

Y

bytePersistDequeues

count64

Persistent messages dequeued

Y

consumerCount

hilo32

Current consumers on queue

Y

bindingCount

hilo32

Current bindings

Y

unackedMessages

hilo32

Messages consumed but not yet acked

It would seem more useful on a per subscription basis (so we can see which subscriptions are holding on to messages without acking them).GS: I agree

messageLatency

mmaTime

Broker latency through this queue

This generates a number of statistics (Max/Min/Avg/Samples) each of which is said to be measured in nanoseconds. What does Samples mean in this context?this isn't actually implemented on c++ yet

sessionRef

objId

Y

queueRef

objId

Y

name

sstr

Y

browsing

bool

Y

is this supposed to be a pre/non acquire indicator? Is this  true only when pre-acquiring and pre-acquiring and accept-mode is none?This is true of the acquire-mode was not-acquired (for 0-10). It is independent of the accept-mode is none?which is exposed via the acknowledged property

acknowledged

bool

Y

is this simply accept-mode = explicit?yes

exclusive

bool

Y

creditMode

sstr

WINDOW or CREDIT

Y

arguments

map

Y

vhostRef

objId

Y

address

sstr

Y

Is this the local or remote address?  Whichever, we should also have the other one. It is the remote address

incoming

bool

Y

SystemConnection

bool

Infrastucture/ Inter-system connection (Cluster, Federation, ...)

Y

federationLink

bool

Is this a federation link

Y

authIdentity

sstr

authId of connection if authentication enabled

Y

remoteProcessName

sstr

Name of executable running as remote client

These are a subset of the clientProperties sent by the client - should we not just show the client Props?

remotePid

uint32

Process ID of remote client

remoteParentPid

uint32

Parent Process ID of remote client

vhostRef

objId

Y

host

sstr

Y

port

uint16

Y

transport

sstr

Y

What are the valid transports? at present, tcp, rdma and ssl(which is over tcp)

durable

bool

Y

state

sstr

Operational state of the link

Are the valid states defined anywhere? c++ broker currently includes the following states: WAITING, CONNECTING, OPERATIONAL, FAILED, CLOSED, PASSIVE (from Link.h) Are the valid states defined anywhere?

lastError

sstr

Reason link is not operational

linkRef

objId

Y

channelId

uint16

Y

durable

bool

Y

src

sstr

Y

dest

sstr

Y

key

sstr

Y

srcIsQueue

bool

Y

srcIsLocal

bool

Y

tag

sstr

what is this and what does it do? It is used for loop detection and is the value to be used for qpid.trace.id on the subscription queue

excludes

sstr

what is this and what does it do? Also used for loop detection and is the value to be used for qpid.trace.excludes on the subscription queue

dynamic

bool

Y

sync

uint16