> ...Artemis uses the phrase *queue* for an architectural concept... To be clear, it's more than a concept. It's a concrete data structure with FIFO semantics.
> ...the documentation sometimes use the word "queue" without > qualify if it refers to the Artemis architectural concept of a queue > or an JMS queue. Let me know if you find any of these ambiguous uses. I've been trying to weed them out for a while. The "Address Model" chapter was overhauled in the not-too-distant past to help clarify how all this works. > ...the example for wildcard routing uses the adress names > "queue.news.#", "queue.news.europe", etc. I can see how that would be confusing, and I've updated the doc [1] to clarify. It's worth noting that the actual JMS topic hierarchy example [2] doesn't use the "queue." prefix. > There will be a message listener backed by a thread pool. But there's still just a single message listener (i.e. a single consumer)? If so, and even if that single consumer dispatches messages to other threads for processing, every message is still funnelled through one consumer on both the client and server (as well as a single queue when using wildcard routing). For what it's worth, this won't scale as well as true concurrent consumers. It's also worth noting that a single JMS Consumer using multiple threads to process messages can be tricky given that JMS Session objects are not thread-safe. Justin [1] https://github.com/apache/activemq-artemis/blob/main/docs/user-manual/wildcard-routing.adoc [2] https://github.com/apache/activemq-artemis-examples/blob/main/examples/features/standard/topic-hierarchies/src/main/java/org/apache/activemq/artemis/jms/example/TopicHierarchyExample.java On Sun, Jun 8, 2025 at 7:29 AM Fredrik Jonson <fred...@jonson.org> wrote: > Justin Bertram wrote: > > > 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. > > Right, now that you mention it the documentation about wildcard routing > specifically points out that this is a feature targeting JMS topics. > > I think what throws me off track, still, even after all these years > using Artemis is that Artemis uses the phrase *queue* for an architectural > concept that implements both JMS Queues, i.e anycast, and JMS Topics, i.e > multicast. > > And as a side note, the documentation sometimes use the word "queue" > without > qualify if it refers to the Artemis architectural concept of a queue or an > JMS queue. And the example for wildcard routing uses the adress names > "queue.news.#", "queue.news.europe", etc. > > Or, is it just me? Do Artemis users generally prefix their JMS topic > addresses "queue." simply because Artemis internally handles it in an > Artemis multicast queue? :) > > > 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. > > Right, thanks for the confirmation! > > > 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"? > > The system has an api for runtime modification of endpoints. When new > messages are created all targeted endpoint's queue address names are > retrieved from that api. > > > Also, by funnelling all messages through a single consumer are you not > > essentially reintroducing a "head of line blocking between unrelated > > target endpoints" problem? > > Sorry, I was unclear. When I wrote single consumer I meant a single > implementation, not a single threaded message consumer instance. > There will be a message listener backed by a thread pool. > > Normally there will also be an even inflow of messages per endpoint, > which I expect will result in a roughly evenly distribution of > target endpoints processed by the pool of shared consumers. Obviously > we have to consider misbehaving or slow consumers/endpoints, etc. > > > 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? > > Yes, but I was hoping avoid that. :) > > Since the endpoint api is part of the system, we could add or remove > dedicated message listeners per queue on demand when the endpoint > inventory is modified. > > The point of sharing a joint consumer/listener pool for multiple queues > and endpoints is to simplify resource management. In the ideal case it > scales down to a single consumer thread processing all messages > for all endpoints. It also allows us to control resource requirements > in worst case scenarios by setting the max size of the listener pool. > > Thanks! > -- > 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 > > >
