Re: [Artemis, AMQP] last-value queue question: nondestructive consumers

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

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

Re: [Artemis, AMQP] last-value queue question: nondestructive consumers

[Lionel van den Berg <li...@gmail.com>]

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.pearce@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 <
> danlangford@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
>