> Is it feasible to attempt to remove the message from the adressed original > queue using the management api?
It is technically feasible to remove a message from a queue using the management API. The 3-step process you outlined would work, in general. The problem is dealing with failure conditions that leave your data inconsistent. For example, if a message was consumed from the wildcard queue but removing it from the "original" queue using the management API failed for some reason (e.g. application crashed, network was interrupted, etc.). Now you need a way to reconcile the data which adds complexity. Typically when working with multiple queues you can rely on a transaction for consistency, but a transaction isn't feasible in this situation. > Would the method `QueueControl.removeMessage(long)` in the management > api work? Yes. I believe that method would technically work in your use-case. However, I think the separation here between the queue from which the messages are actually being consumed and the queue you're actually monitoring is going to lead to trouble one way or another. > I mean, assuming `removeMessage()` is at least somewhat okay-ish from > a performance perspective. I expect it will be significantly slower than acknowledging the message via an actual consumer, perhaps an order of magnitude slower. Will that actually matter for your use-case? Only testing will tell. > The problem of HOL-blocking in the "q.#" queue would remain, AFAICT? That's correct. Justin On Sun, Jun 8, 2025 at 8:43 AM Fredrik Jonson <fred...@jonson.org> wrote: > 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 > > >
