This is an interesting thread to me. We are trialling right now using retroactive on the AMQ 5.14.x in a k,v type way.
I had thought to try with Artemis in the future using LVQ + multiplexing (I think it was). On Tue, 1 May 2018 at 3:27 pm, michael.andre.pearce < michael.andre.pea...@me.com> wrote: > Have you tried making the session client acknowledge and simply not > acknowledging the message? > It is the acknowledge that removes it, so by not acknowledging the message > would remain for when you restart your consumer. > Currently there is no retroactive support which would be the golden grail > here, I also would like this then it could be really used like a k,v store > (akin to kafka compacted and ktables). > CheersMike > > > Sent from my Samsung Galaxy smartphone. > -------- Original message --------From: Dan Langford < > danlangf...@gmail.com> Date: 30/04/2018 22:58 (GMT+00:00) To: > users@activemq.apache.org Subject: [Artemis, AMQP] last-value queue > question: nondestructive consumers > currently using Artemis 2.5.0 and AMQP in our tests > question in short: > is there an ability to force last-value queue consumers to be > non-destructive so the messages remain on the queue? > > a cool use case which we do in the QPID java broker is we create a > last-value queue and in the broker we can configure the queue to force all > consumers to be non-destructive. the result is a cool "configuration" > server where we store config that needs to be shared and pushed to multiple > pieces of our system. when the consumer connects it treats all existing > messages as "new" and delivers them pushing down to them our configuration > immediately when the application connects. later when messages are sent > into this last-value queue essentially "updating" or replacing old messages > the new messages are sent to all existing consumers. it creates a cool > approach where config is delivered first-time and in real-time. > first-time/real-time. > > is there any option on the broker side or the client side to force a > connection to act like a normal connection but to be non-destructive. i > guess the client side we are using is the qpid-jms-client but if the > artemis CORE client has an option we would consider switching. a broker > side option would be ideal. > > thanks > dan langford >
