currently using Artemis 2.5.0 and AMQP in our tests question in short: should we be able to use last-value queue and message delay/scheduling together and have scheduled messages be considered as part of the last-value queue features.
Some of the teams here have started exploring some interesting things they can do with the broker which seems to be pretty useful but then we hit a couple snags and questions. Using a Last-Value queue we can put a message on the queue and then essentially "change" or "update" the message by producing one with the same value in _AMQ_LVQ_NAME. its really just replacing the old message with the new one but if the new one looks nearly identical it feels like an update to the message. so the team is able to change things like the messages expiration time and the message priority. But the team tried to change the message delay and it didnt work. instead it just scheduled another message. i did some digging and from what i can tell the reason why is because a message delay, or a message scheduled for delivery, is held onto by the broker prior to being placed on the queue and it seems that last-value queue only "works" or "considers" messages that are currently on the queue. Does this seem like an accurate description of our problem? the teams hope was to schedule the message for delivery in a couple days. and then if they needed to change the content or the delivery time they could reproduce the message with the same _AMQ_LVQ_NAME essentially updating the message with a new time. if they wanted to delete the message they could update the message with an immediate expiration. that sounds nice but doesnt seem to function like that. is there a way to "effect" messages that are scheduled at all via JMS? any way to overwrite them like last-value was doing? or any way to delete them or force their expiration via JMS prior to their scheduled delivery time? i do know of one hack or workaround. i know back when rabbit didnt support message delays what we did was put a message in a queue with a message specific expiration. this was our "fermentation" queue. and then when it expired the message was dumped onto a expiration queue which is where the consumers were listening for it. i imagine we could hack together something similar where our "fermentation" queue is a last-value queue and we use the message expiration as a delivery time and we could "update" the message expiration time as needed using last-value features. thanks dan langford
