On 01/18/2011 03:31 PM, Bruno Matos wrote:
On 2011/01/12, at 17:33, Gordon Sim wrote:
On 01/11/2011 04:30 PM, Bruno Matos wrote:
I'm publishing messages to a durable LVQ, when I run the publisher for
the first time the journal stays almost full, then I send the exact same
messages, expecting the old ones to be replaced, but after some time the
connection is closed with "Enqueue capacity threshold exceeded on
queue". With qpid-tool I can see that msgDepth and byteDepth are exactly
the same before and after the second run. Is this the expected behavior?
Depends on what you mean by 'expected' :-)
It is certainly the case that the linux journal will reach capacity
with different queue depths, depending on exact sequences of changes.
i.e. the capacity is not simply a function of the final state, but
also of the path to get there. In the second case there would be
additional dequeue records and the file boundaries might not align the
same way etc, so the journal space can be used up for fewer enqueued
messages.
Thank you Gordon.
I think I can say that's the expected to me... :) Although I need to
know what journal size is effectively in use, can be a percentage, is
that possible? I have a stored queue for browsing, like a dictionary,
that is updated every night, and I want to reset it only if it reaches
to a given percentage of journal size.
Not sure if I understand the question correctly, but there is no simple
way of determining the minimum journal size needed to guarantee a
specific queue depth. The rule I use is to size the journal much larger
than I think I need (e.g. 2x the queue depth). Kim has some text
somewhere on the calculations involved I believe.
Its also worth then setting a queue policy on the queue with the depth
fixed (and significantly less than the journal capacity). That way you
get a cleaner error when you hit the limit.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]