On 26 March 2013 12:45, Gordon Sim <[email protected]> wrote:

> On 03/25/2013 10:16 PM, Rob Godfrey wrote:
>
>>   The implementation of persistence in
>> the C++ broker pretty much forced them to define ring queues.
>>
>
> Actually the introduction of ring queues was not driven by the store at
> all. It came from use cases where build up of queues beyond a given point
> was undesirable and where the older messages could be ignored in those
> cases. They effectively implement a policy of 'only keep the last N
> messages', whereas say using a TTL would be a policy of 'only keep messages
> for T seconds'.
>
>
>   That's not
>> to say that there aren't non-persistent use cases for them.  The
>> subtleties
>> are about what happens when consumption from the queue is not strictly
>> FIFO.  The C++ persistent queue implementation literally is a ring.  Thus
>> is you have non-FIFO consumption you can get "ring" overwriting even when
>> the number of unconsumed messages in the queue is less than the ring size.
>>
>
> The store will not overwrite, it will simply refuse to enqueue more if
> there is no more space (that may indeed be when there is only one message
> still enqueued, if it happens to be at the start of the 'ring'). The ring
> buffer used in the journal is entirely distinct from the ring queues in
> memory (which can for example evict out of order, based on priority).
>
>
>
Many apologies for my misunderstanding...

In this case there shouldn't be a big barrier to implementing bounded queue
sizes in the same way in the Java Broker. I find the "ring" name somewhat
confusing then as the implementation is not actually a ring but simply a
bounded buffer where the oldest unconsumed message is discarded when the
queue size hits the bound.

Is there any special treatment of priority queues (do you discard lower
priority messages in preference to higher priority), or is the aging strict?

Cheers,
Rob


> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: 
> [email protected].**org<[email protected]>
> For additional commands, e-mail: [email protected]
>
>

Reply via email to