Re: [Artemis, AMQP] last-value queue questions: msg-delay

["michael.andre.pearce" <mi...@me.com>]

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 <da...@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