This is expected behaviour, scheduled delivery is about delaying the delivery of the message into the queues. Use case here is like delayed price quotes on exchange (in fact this is how we use it where I work), idea is all messages are sent to the broker with say a 5 minute schedule for delivery, and effectively you now have a 5 min delayed price stream. E.g. I send a message as a producer but the broker holds off delivering this until the time set in the future. To do what you are wanting would require new broker features from my knowledge (happy for one of the other committers to correct me here). We always welcome contributions here thougg so if you wanted to implement some feature to support your use case please feel free. Cheers.Mike
Sent from my Samsung Galaxy smartphone. -------- Original message --------From: Dan Langford <danlangf...@gmail.com> Date: 30/04/2018 22:57 (GMT+00:00) To: users@activemq.apache.org Subject: [Artemis, AMQP] last-value queue questions: msg-delay 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