Justin Bertram wrote: > 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?
Speaking of Artemis management api: Is it feasible to attempt to remove the message from the adressed original queue using the management api? Basically: 1. Send messages to "q.a", "q.b", etc. 2. Consume the copies of the messages that are sent to the queue "q.#". 3. If a copy is successfully processed in step 2, use the management api to remove the original message from queue "q.a". Would the method `QueueControl.removeMessage(long)` in the management api work? Is the same messageID used for both the original sent to "q.a" and the copy sent to "q.#"? `(ActiveMQMessage) message).getCoreMessage().getMessageID()`? If that approach is practical, it seems like a partial solution to my problem. I mean, assuming `removeMessage()` is at least somewhat okay-ish from a performance perspective. It would drain messages from the endpoint queues when their copies are consumed from the wildcard consumer, which was the showstopper for the initial attempt. It would also be possible to monitor the endpoint queues, measuring throughput, backlogs, misbehaviour, etc. The problem of HOL-blocking in the "q.#" queue would remain, AFAICT? Perhaps that could be controlled by strict processing timeouts. Possibly combined with dedicated retry queues to keep undelivered messages from blocking consumers on the "q.#" Artemis queue, if that's necessary? 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
