You are using auto-create-queues....
I would recommend you create the queue on multicast:
<address name="foobar">
<multicast>
<queue name="foobar"/>
</multicast>
</address>
I'm not talking about JMS Queues, I'm talking about internal queues.
On Mon, Jun 7, 2021 at 5:42 AM La Fleur, Sebastiaan
<sebastiaan.lafl...@ns.nl.invalid> wrote:
>
> Good morning Clebert,
>
> Thank you for the tip! I can confirm that this is not due to the auto delete
> of the queue. The queue commands have the durable flag which sets the durable
> value of AMQP to Configuration which in turn leads to a durable, persistent
> queue on the Artemis broker.
>
> Also, the ALL command is created exactly the same and is persistent over
> reconnects and does relay all pending messages.
>
>
> Regards,
>
> Sebastiaan la Fleur
>
> -----Original Message-----
> From: Clebert Suconic <clebert.suco...@gmail.com>
> Sent: zaterdag 5 juni 2021 00:20
> To: users@activemq.apache.org
> Subject: Re: Understanding of Artemis multicastPrefix in AMQP address
> prevents the transfer of historical and pending messages of queue
>
> you should always receive messages from the point you create a queue on...
>
>
> you are probably removing the queue with auto-delete? I'm looking to disable
> auto-delete on auto created queues.. as I have seen many questions around it.
> can you take a look if you are deleting a queue that was auto-created?
>
> On Fri, Jun 4, 2021 at 7:22 AM La Fleur, Sebastiaan
> <sebastiaan.lafl...@ns.nl.invalid> wrote:
> >
> > Good afternoon all!
> >
> > Artemis version: 2.17.0
> >
> > This week I ran into a behavior of Artemis that I did not expect nor fully
> > understand so I hope that with this e-mail someone is able to point me to
> > the relevant documentation.
> >
> > TL;DR:
> > Say we have a durable queue configured connected as multicast to the
> > address (so it is a topic) and we have a sender who sends a durable message
> > to the queue every 1 second with a different body.
> > Then we can connect a receiver and depending on if the multicast address
> > prefix is added, all pending and new messages are received or only new
> > messages are received.
> >
> > Details:
> > Queue configuration in broker.xml:
> > <address-setting match="foobar">
> > <max-size-bytes>100000000</max-size-bytes>
> > <page-size-bytes>10000000</page-size-bytes>
> > <address-full-policy>BLOCK</address-full-policy>
> > <auto-create-queues>true</auto-create-queues>
> > <auto-create-addresses>false</auto-create-addresses>
> > <auto-create-jms-queues>false</auto-create-jms-queues>
> > <auto-create-jms-topics>false</auto-create-jms-topics>
> > <min-expiry-delay>60000</min-expiry-delay>
> > <max-expiry-delay>604800000</max-expiry-delay>
> >
> > <default-address-routing-type>MULTICAST</default-address-routing-type>
> > </address-setting>
> >
> > <address name="foobar">
> > <multicast>
> > </multicast>
> > </address>
> >
> > I have been able to reproduce this using the Artemis CLI client:
> >
> > To produce $ ./artemis producer --user someUser --password somePW
> > --url amqp://localhost:5672 --sleep 1000 --protocol amqp --destination
> > topic://foobar --verbose
> >
> > To consume ALL $ ./artemis consumer --durable --protocol amqp --user
> > someUser --password somePW --clientID artemisconsole --destination
> > topic://foobar --url amqp://localhost:5672 --verbose
> >
> > To consume NEW only $ ./artemis consumer --durable --protocol amqp
> > --user someUser --password somePW --clientID artemisconsole
> > --destination topic://multicast:foobar --url amqp://localhost:5672
> > --verbose
> >
> > The producer command runs in the background and is continuously sending
> > messages. Now if I run the ALL consume command, the queue is created and I
> > will receive messages from that point on. If I quit the command with
> > (CTRL+C), wait a couple of seconds and run the ALL command again, I will
> > receive all queued, pending messages and any new messages.
> >
> > Now if I run the NEW consume command, another queue is created and I will
> > receive messages from that point on. If I quit the command with (CTRL+C),
> > wait a couple of seconds and run the NEW command again, I will NOT received
> > the queued, pending messages and will ONLY receive the messages that are
> > new from that point on. All pending, queued messages are removed and the
> > queue gets a new ID according to queue attributes in the management web ui.
> >
> > The only difference between the 2 receiver commands is the addition of the
> > multicast: prefix in the Artemis/AMQP address.
> >
> > Now if I look in the web GUI, I do see that the queue attribute ID
> > stays the same whenever the ALL command (re)connects while the queue
> > attribute ID changes whenever the NEW command (re)connects. An example
> > of where I found this id: https://imgur.com/a/pmJPnkd
> >
> > I have discovered this behavior with a programmatic Python Proton client
> > but the steps written in this e-mail uses the artemis binary to make it
> > easily reproducible and show the behavior probably originates from the
> > broker.
> >
> > Curious to hear if this is expected behavior! Could someone point me to the
> > relevant documentation?
> >
> >
> > Thank you in advance!
> >
> > Sincere regards,
> >
> > Sebastiaan la Fleur
> >
> >
> >
> >
> >
> >
> > ________________________________
> >
> > Deze e-mail, inclusief eventuele bijlagen, is uitsluitend bestemd voor
> > (gebruik door) de geadresseerde. De e-mail kan persoonlijke of
> > vertrouwelijke informatie bevatten. Openbaarmaking, vermenigvuldiging,
> > verspreiding en/of verstrekking van (de inhoud van) deze e-mail (en
> > eventuele bijlagen) aan derden is uitdrukkelijk niet toegestaan. Indien u
> > niet de bedoelde geadresseerde bent, wordt u vriendelijk verzocht degene
> > die de e-mail verzond hiervan direct op de hoogte te brengen en de e-mail
> > (en eventuele bijlagen) te vernietigen.
> >
> > Informatie vennootschap<http://www.ns.nl/emaildisclaimer>
>
>
>
> --
> Clebert Suconic
>
> ________________________________
>
> Deze e-mail, inclusief eventuele bijlagen, is uitsluitend bestemd voor
> (gebruik door) de geadresseerde. De e-mail kan persoonlijke of vertrouwelijke
> informatie bevatten. Openbaarmaking, vermenigvuldiging, verspreiding en/of
> verstrekking van (de inhoud van) deze e-mail (en eventuele bijlagen) aan
> derden is uitdrukkelijk niet toegestaan. Indien u niet de bedoelde
> geadresseerde bent, wordt u vriendelijk verzocht degene die de e-mail verzond
> hiervan direct op de hoogte te brengen en de e-mail (en eventuele bijlagen)
> te vernietigen.
>
> Informatie vennootschap<http://www.ns.nl/emaildisclaimer>
--
Clebert Suconic
