Erik, Justin,
Is this related to https://issues.apache.org/jira/browse/ARTEMIS-3159 (solved
in 2.18.0) ?
That one was about expiry of messages on multiple queues under one address.
Both expiry and multi-nack are about moving messages to a secondary destination
(ExpiryQueue or DLQ).
Erwin
-----Oorspronkelijk bericht-----
Van: Justin Bertram <jbert...@apache.org>
Verzonden: maandag 31 januari 2022 19:24
Aan: users@activemq.apache.org
Onderwerp: Re: Multiple queues in address + DLQ problem?
EXTERNAL SENDER: Do not click any links or open any attachments unless you
trust the sender and know the content is safe.
EXPÉDITEUR EXTERNE: Ne cliquez sur aucun lien et n’ouvrez aucune pièce
jointe à moins qu’ils ne proviennent d’un expéditeur fiable, ou que vous ayez
l'assurance que le contenu provient d'une source sûre.
There's lots of moving pieces here and the devil is in the details, as they
say. I think we'd need some kind of test-case to reproduce (ideally _without_
Quarkus) what you're seeing in order to investigate this.
Justin
On Sun, Oct 24, 2021 at 7:43 AM Erik Åsén <ease...@gmail.com> wrote:
> Hi!
> First of all, I don't have any logs of the event but was able to
> reproduce it frequently or actually always. In ActiveMQ Artemis 2.16.X
> (running in a pod in podman on a wsl2 ubuntu 20.04) is there a problem
> when having multiple queues in an address and a microservice with two
> consumers consuming and nacking messages? The problem I'm finding is
> that when a nack is sent back from one of the consumers on either
> queue, I use the address::queue to access a specific queue, the auto
> created DLQ.<address> is created but the queue has no messages on it
> like it usually has when only one queue exists on the address. The big
> DLQ queue has the message, but the filter that usually assigns the
> nacked message to the auto created multicast queue doesn't seem to
> understand what to do even though the nacked message contains the original
> destination queue and address.
> I found two workarounds and both don't feel that great but they do the
> jobb I think. First is to specify the dead-letter-address in the
> broker.xml with the value DLQ::DLQ.<address> which kinda works.. kinda
> because it feels like one message is lost into ciberspace, didn't
> study it that much since my teammates choose to split the queues into
> different addresses instead also looked like the first one to get
> nacked was missing, when the auto create happens for the DLQ.<address>
> and the second was to use the first fix but this time also precreating the
> DLQ.<address> in the DLQ address.
>
> Specs of microservice
> Quarkus 2.2.3
> SmallRye Reactive Messaging (quarkus-smallrye-reactive-messaging-amqp)
>
> Annotation used
> @Channel("<channel-name>") on a string emitter.
> @Incoming("incoming1") on an annotated method with a Message<String>
> input.
> @Incoming("incoming2") annotated on a different method with a
> Message<String> input.
>
> Configuration in quarkus
> mp.messaging.incoming.requests.connector=smallrye-amqp
> mp.messaging.incoming1.requests.address=<address>::queue1
> mp.messaging.incoming2.requests.failure-strategy=modified-failed
> mp.messaging.incoming2.requests.connector=smallrye-amqp
> mp.messaging.incoming2.requests.address=<address>::queue2
> mp.messaging.incoming2.requests.failure-strategy=modified-failed
>
> With kind regard
> Erik
>
