Hi Domenico, Thanks for the rapid response!
If I interpret your words correctly, the same underlying logic powers both the web console and the CLI browser command. If this is the case, it is somewhat puzzling that they produce different results. (As I mentioned, the web console can browse through all 180000+ messages, while the CLI only dumps 50000-80000 messages.) Also, if the web console and the CLI browser command has by design limitations for queue size, then these limitations should be explicitly stated at several places such as: * The on-screen help / instruction popup of the web console's browse queue page. * The help page of the artemis browser subcommand. * In the use manual, e.g. https://activemq.apache.org/components/artemis/documentation/latest/using-cli.html I'm gonna take a look at the JMS client next. Again, thanks for the response! CSIPAK Attila -----Original Message----- From: Domenico Francesco Bruscino <bruscin...@gmail.com> Sent: Tuesday, February 6, 2024 2:52 PM To: users@activemq.apache.org Subject: Re: CLI browser does not return all messages Hi Attila, the QueueControl.browse management method is not designed to be used with such a big number of messages at a time. It was designed to provide the browse feature to the web console that browses 10 messages at a time. I would recommend using a JMS client to browse such a big number of messages, i.e. https://github.com/apache/activemq-artemis-examples/tree/main/examples/features/standard/browser Regards, Domenico On Tue, 6 Feb 2024 at 12:50, Csipak Attila <csipak.att...@cetelem.hu.invalid> wrote: > Hello, > > We have a couple of ActiveMQ Artemis v2.25.0 instances running. > > What I am trying to do is to create a dump file of all messages that > landed in DLQs. > > I experimented a little with the CLI, and came up with commands such > as > this: > > ./artemis browser --url tcp://hostname:61616 --destination queue://DLQ > --message-count 200000 > > This command works well in cases where the DLQ is relatively small. If > we run it on a DLQ with ~700 messages, the command consistently > returns all of them. > > However, we have a case where the DLQ contains 180000+ messages (hence > the message-count option) and at this point, the above command does > not behave so well. > > The "browsed: X messages" line at the end of the CLI output shows > different message counts for every run: 66940, 70598, 59670, 58028, > 63878 etc. These message counts are always significantly less than the > correct size of the DLQ as seen on management console. > > We can safely rule out the possibility of the DLQ contents changing > this much between CLI runs. No messages are being removed from this > DLQ. Instead there's a slow-paced influx of undelivered messages to the DLQ. > > If this is a bug, I'm interested in any potential fixes and workarounds. > > I can also provide more details if requested. > > Thanks in advance. > > CSIPAK Attila > > ---Disclaimer--- > > This is a confidential e-mail. Magyar Cetelem Zrt. may monitor and > record all e-mails. The views expressed in this e-mail are those of > the sender and not Magyar Cetelem Zrt. Do not print this message > unless it is necessary, consider the environment. > ----Nyilatkozat---- Az ebben az e-mailben közölt információk bizalmas jellegűek. A Magyar Cetelem Zrt. jogosult minden e-mail kommunikáció monitorozására és rögzítésére. Az e-mail üzenet tartalma a feladó nézeteit tükrözi, amely nem feltétlenül egyezik meg a Magyar Cetelem Zrt. nézeteivel. Védje a környezetet, ezért ezt az üzenetet csak szükség esetén nyomtassa ki. Magyar Cetelem Zrt., 1062. Teréz körút 55-57. ----Disclaimer--- This is a confidential e-mail. Magyar Cetelem Zrt. may monitor and record all e-mails. The views expressed in this e-mail are those of the sender and not Magyar Cetelem Zrt. Do not print this message unless it is necessary, consider the environment. Magyar Cetelem Zrt., 1062. Teréz körút 55-57.