-
1. Re: Round-robin queue mode
ataylor Apr 12, 2014 8:09 AM (in response to ulf.schroeter)could you exlain a bit more what you mean by a 'round robin queue'. what is being is being round robined? if you replace the first message on the queue where does the next message go?
-
2. Re: Round-robin queue mode
ulf.schroeter Apr 12, 2014 9:15 AM (in response to ataylor)Hi Andy,
maybe "last-x-messages queue" is a simpler explanation (were x specifies the user-definable upper count of stored messages). While a last-message queue only stores 1 last message, we would like to store the last x send messages. On new message insert - in case there are already x messages stored in this queue - the oldest stored message should be simply dropped from the queue.
Remark: I know that last-message queue operates on a message-property-level within a queue, but at the moment I am uncertain if we would need the discussed feature on message-property level or just on queue level).
To further illustrate our use-case: we would like to have a topic with multiple durable subscriptions (address + multiple bound persistent queues). Messages will be inserted continously e.g. 100 msg/min while the individual consumers will only re-connected at certain times e.g. once per hour for just 1 minute.
On re-connect each individual consumer should only receive the newest published 100 messages (= 1min) before re-connect and all follow-up messages send while connected/online for 1min, but not the 5800 messages (58 min) send previously after the consumer went offline in the previous activity cycle.
Hope this explains the targeted functionality better.
-
3. Re: Round-robin queue mode
ataylor Apr 12, 2014 9:46 AM (in response to ulf.schroeter)maybe "last-x-messages queue" is a simpler explanation (were x specifies the user-definable upper count of stored messages). While a last-message queue only stores 1 last message, we would like to store the last x send messages. On new message insert - in case there are already x messages stored in this queue - the oldest stored message should be simply dropped from the queue.
Ok, I get it, the round robin comment thru me. So, no we currently cant do that. Implementing this wouldn't be too hard so feel free to raise a JIRA if you want. Unfortunately its unlikely that we could get round to doing this any time soon but we would always welcome contributions.
Remark: I know that last-message queue operates on a message-property-level within a queue, but at the moment I am uncertain if we would need the discussed feature on message-property level or just on queue level).
i would say it would be a new type of queue, maybe 'bounded queue' or something.
To further illustrate our use-case: we would like to have a topic with multiple durable subscriptions (address + multiple bound persistent queues). Messages will be inserted continously e.g. 100 msg/min while the individual consumers will only re-connected at certain times e.g. once per hour for just 1 minute.
On re-connect each individual consumer should only receive the newest published 100 messages (= 1min) before re-connect and all follow-up messages send while connected/online for 1min, but not the 5800 messages (58 min) send previously after the consumer went offline in the previous activity cycle.
One thing we would need to decide would be how to handle message buffering, the client could have 200 messages buffered, if it consumes 100 the 100 will be put back on the queue (usually the head), but this will break semantics as other new mesages may have arrived at the queue since. of course you could set the buffer size to 0.