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
