I think the first thing to remember here is that the functionality you're using is underpinned by wildcard *routing* [1] which is similar, but not equivalent, to wildcard consuming. Wildcard routing was mainly designed for multicast use-cases (e.g. topic hierarchies) although it will work with anycast as well with some caveats - one of which you're asking about here.
> Step 1 - 3 works, step 4 doesn't. The behavior you're observing is expected given the semantics of wildcard routing. As you suspect, the consumer is receiving a copy of the message. The purposes you outlined make sense, generally speaking. However, the devil is in the details. For example, how will the destinations be "modified at runtime"? Also, by funnelling all messages through a single consumer are you not essentially reintroducing a "head of line blocking between unrelated target endpoints" problem? Have you considered creating an individual consumer for each destination and either using management notifications or polling the management API to find out about new queues? Justin [1] https://activemq.apache.org/components/artemis/documentation/latest/wildcard-routing.html#routing-messages-with-wild-cards On Sat, Jun 7, 2025 at 6:12 AM Fredrik Jonson <fred...@jonson.org> wrote: > Hi all, > > Is it possible to have a wildcard consumer acknownledge messages in their > originally addressed queues? > > I'm attempting to consume messages from multiple dynamically created > anycast > JMS queues in Artemis. For that purpose I created a consumer for a wildcard > adress. The wildcard matches a some dynamically created anycast queue > names. > All named queues have the same the message processing, but each address > have > a different external message recipient endpoint. > > E.g: > > 1. Create consumer C for wildcard address "q.#". > > 2. Submit a message to anycast adress "q.a". > > 3. Have C receive the message from "q.a" via its subscription to "q.#". > > 4. Have the message on the anycast queue "q.a" acknowledged when the > consumer C in step 3 acknowledges the message it consumed from "q.#". > > Step 1 - 3 works, step 4 doesn't. > > While the message submitted to "q.a" is delivered to the consumer, it seems > that the message on "q.a" remains in that queue even after C has consumed > it > on "q.#". Did C consume a copy? > > The purpose of this setup is to be able to have a static configuration of a > message listener for multiple destinations that can be modified at runtime. > > The purpose of separating the endpoints by queue names is to simplify > monitoring of throughput and backlog per endpoint by queue name, and to > avoid head of line blocking between unrelated target endpoints. > > Is this approach, or something like it supported? Is there an alternative? > > I read about diverts, but AFAIU, what I need is "fan-in" rather than a > fan-out, > and I'd like the messages to stay in their original queues until consumed. > > As always, any hints appreciated. :) > > -- > Fredrik Jonson > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@activemq.apache.org > For additional commands, e-mail: users-h...@activemq.apache.org > For further information, visit: https://activemq.apache.org/contact > > >
