Re: byteDepth only as uint32?

2011-09-06 Thread Gordon Sim

On 09/05/2011 08:44 PM, Fraser Adams wrote:

One thing I'm more concerned about is whether this only relates to
statistics or is more insidious.

Gordon Sim spoke of a bug whereby the maximum queue size was 4GB due to
the use of a uint32.


Just to be clear that was the maximum configurable limit (an unlimited 
queue could be larger assuming you had the memory).



Apparently this has been resolved for Qpid 0.12
(though I've not tried this myself) but I'm interested about other
uin32s around. For example it's possible to trigger an event if a queue
threshold has been exceeded I'm hoping that the attribute used to hold
that threshold got changes to a uin64 at the same time as the attribute
used to hold the queue size otherwise the events are going to bear no
relationship to real triggers for large queues.


The threshold tracking code does indeed use a uint64.

-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:users-subscr...@qpid.apache.org



byteDepth only as uint32?

2011-09-05 Thread Jakub Scholz
Hi,

The current schema (well, current ... Qpid 0.10 / MRG 2.0) for a queue
seems to handle byteDepth only as uint32:

qpid: schema queue
Object Class: Table Class:
org.apache.qpid.broker:queue:_data(bfd4d378-c6e6-efb6-f0d0-963252cedfaa)
ElementType  Access  Unit  Notes
Description

===
vhostRef   reference ReadCreateindex
name   short-string  ReadCreateindex
durableboolean   ReadCreate
autoDelete boolean   ReadCreate
exclusive  boolean   ReadCreate
arguments  field-table   ReadOnly
Arguments supplied in queue.declare
altExchangereference ReadOnly  optional
msgTotalEnqueues   uint64
msgTotalDequeues   uint64
msgTxnEnqueues uint64
msgTxnDequeues uint64
msgPersistEnqueues uint64
msgPersistDequeues uint64
msgDepth   uint32
byteDepth  uint32
byteTotalEnqueues  uint64
byteTotalDequeues  uint64
byteTxnEnqueuesuint64
byteTxnDequeuesuint64
bytePersistEnqueuesuint64
bytePersistDequeuesuint64
consumerCount  uint32
consumerCountHigh  uint32
consumerCountLow   uint32
bindingCount   uint32
bindingCountHigh   uint32
bindingCountLowuint32
unackedMessagesuint32
unackedMessagesHighuint32
unackedMessagesLow uint32
messageLatencySamples  delta-time
messageLatencyMin  delta-time
messageLatencyMax  delta-time
messageLatencyAverage  delta-time
flowStoppedboolean
flowStoppedCount   uint32

Given the possibilities of Qpid, the uint32 seems to be a limitation.
I already got into situations, where uint32 is not sufficient and one
has to use the enqueue and dequeue statistics to calculate the actual
byte depth:

msgDepth   3155
byteDepth  3421958148
byteTotalEnqueues  24896794628
byteTotalDequeues  0

I entered a JIRA QPID-3465 for this problem.

Regards
Jakub

-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:users-subscr...@qpid.apache.org



Re: byteDepth only as uint32?

2011-09-05 Thread Fraser Adams
One thing I'm more concerned about is whether this only relates to 
statistics or is more insidious.


Gordon Sim spoke of a bug whereby the maximum queue size was 4GB due to 
the use of a uint32. Apparently this has been resolved for Qpid 0.12 
(though I've not tried this myself) but I'm interested about other 
uin32s around. For example it's possible to trigger an event if a queue 
threshold has been exceeded I'm hoping that the attribute used to hold 
that threshold got changes to a uin64 at the same time as the attribute 
used to hold the queue size otherwise the events are going to bear no 
relationship to real triggers for large queues.


I noticed the same thing as you Jakub and I got distracted before I got 
round to posting. Time for a jolly big grep of uin32 usage I think :-)


The Java client runtime has a fair few ints and Integers around too 
where longs would probably be better


Frase

Jakub Scholz wrote:

Hi,

The current schema (well, current ... Qpid 0.10 / MRG 2.0) for a queue
seems to handle byteDepth only as uint32:

qpid: schema queue
Object Class: Table Class:
org.apache.qpid.broker:queue:_data(bfd4d378-c6e6-efb6-f0d0-963252cedfaa)
ElementType  Access  Unit  Notes
Description

===
vhostRef   reference ReadCreateindex
name   short-string  ReadCreateindex
durableboolean   ReadCreate
autoDelete boolean   ReadCreate
exclusive  boolean   ReadCreate
arguments  field-table   ReadOnly
Arguments supplied in queue.declare
altExchangereference ReadOnly  optional
msgTotalEnqueues   uint64
msgTotalDequeues   uint64
msgTxnEnqueues uint64
msgTxnDequeues uint64
msgPersistEnqueues uint64
msgPersistDequeues uint64
msgDepth   uint32
byteDepth  uint32
byteTotalEnqueues  uint64
byteTotalDequeues  uint64
byteTxnEnqueuesuint64
byteTxnDequeuesuint64
bytePersistEnqueuesuint64
bytePersistDequeuesuint64
consumerCount  uint32
consumerCountHigh  uint32
consumerCountLow   uint32
bindingCount   uint32
bindingCountHigh   uint32
bindingCountLowuint32
unackedMessagesuint32
unackedMessagesHighuint32
unackedMessagesLow uint32
messageLatencySamples  delta-time
messageLatencyMin  delta-time
messageLatencyMax  delta-time
messageLatencyAverage  delta-time
flowStoppedboolean
flowStoppedCount   uint32

Given the possibilities of Qpid, the uint32 seems to be a limitation.
I already got into situations, where uint32 is not sufficient and one
has to use the enqueue and dequeue statistics to calculate the actual
byte depth:

msgDepth   3155
byteDepth  3421958148
byteTotalEnqueues  24896794628
byteTotalDequeues  0

I entered a JIRA QPID-3465 for this problem.

Regards
Jakub

-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:users-subscr...@qpid.apache.org


  



-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:users-subscr...@qpid.apache.org