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>
