workaround for buggy persistent limit-policy ring?

[Mike Pomraning <mj...@pilcrow.madison.wi.us>]

This message[0] seems to confirm that persistent ring queues break hard when
they reach capacity, rather than wrapping gracefully.  Further, that
breaking point is rather difficult to compute in advance.

Is there a practicable workaround for those who want persistent storage and
a ring limit policy for a broker's queue?

-Mike

  [0]:
http://mail-archives.apache.org/mod_mbox/qpid-dev/201104.mbox/%3C4DB92366.8090908@redhat.com%3E

Re: workaround for buggy persistent limit-policy ring?

[Carl Trieloff <cc...@redhat.com>]

On 05/03/2011 02:37 PM, Mike Pomraning wrote:
> This message[0] seems to confirm that persistent ring queues break hard when
> they reach capacity, rather than wrapping gracefully.  Further, that
> breaking point is rather difficult to compute in advance.
>
> Is there a practicable workaround for those who want persistent storage and
> a ring limit policy for a broker's queue?
>
> -Mike
>
>   [0]:
> http://mail-archives.apache.org/mod_mbox/qpid-dev/201104.mbox/%3C4DB92366.8090908@redhat.com%3E
>


A quick option is to make sure that the store limits are NOT hit before
the ring limits are reached. As Gordon states this means headers need to
be accounted for. This is the case where the store limit can send a
reject causing the non-expected ring behaviour.

This (store size) can be calculated, or by simply sizing the store
larger, say 2x larger than the ring limit + guess of user header size
then you will not get a reject from store capacity and you ring will
operate as expected. Obviousaly the store can be sized more
scientifically, to optimize disk space.

Carl.



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