qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: Queue's various size limits in the C++ broker.
Date Thu, 06 Mar 2014 15:44:01 GMT
On 03/06/2014 02:58 PM, Bill Freeman wrote:
> On Thu, Mar 6, 2014 at 5:17 AM, Gordon Sim <gsim@redhat.com> wrote:
>> Can you point me at the misleading docs and I'll see if I can make it
>> clearer?
>
>
> The spot I was thinking of is in the output of qpid-config -h:
>
>      --max-queue-size=<n>
>                          Maximum in-memory queue size as bytes
>

Yes, that is indeed a bit vague and imprecise now you mention it. I 
think the wording stems from the (now removed) flow-to-disk policy, 
where the queue can grow above the maximum size, but that requires 
messages to be 'released' from memory and retrieved from disk when 
needed. I.e. in that case it wasn't really a maximum limit, it was a 
level at which certain behaviour was triggered.

[...]
> Ah, yes, now that I'm looking for them:
>      --default-queue-limit
>      --num-jfiles
>      --jfile-size-pgs
> And, since we're not setting them, it's good that qpidd --help gives the
> default defaults.
>
> I wonder if I can (for yet another tool I'm writing that tries to display
> percent full in several categories) get the current default (whether
> default default of configured) using QMF?  I guess I'll poke around in the
> broker agent class.

I believe there is a QMF class for the store. Using qpid-tool try 
`schema store` to see what it has. A quick glance on trunk shows 
"defaultInitialFileCount and "defaultDataFileSize" both being available. 
You can also get the value on the various journals I think.

[...]
> I guess that I tried to abbreviate that question too much.  (Either that or
> I'm too dense to follow your answer.)

No, that would be me not reading the question properly! Sorry!

> msgPersistEnqueues, msgPersistDequeues, bytePersistEnqueues, and
> bytePersistDequeues are queue statistics, not things in the argumenst queue
> property.  I had assumed that they indicated the number and total size of
> messages which had been persisted, so I was surprised to see non-zero
> values for a non-durable queue, none of whose content is persisted.

Looking at the code, those are set purely based on whether the *message* 
is marked as persistent, regardless of whether the queue is actually 
durable (and therefore actually persisting the messages).

[...]
> And now that I think about it, is (bytePersistEnqueues -
> bytePersistDequeues) the aggragate of the original (on the wire) size of
> the messages, as opposed to the size (if the queue is durable) that they
> consume on disk (since this differs).

In 0.18 its not quite the former. On trunk (I think from 0.26 or so) it 
*is* more or less the size on the wire. It isn't the size on disk.


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


Mime
View raw message