artemis-server | A GraphQL enabled server seed | GraphQL library

There is a bug which prevents browsing messages when one of the messages in the queue contains a null property value. In this case the broker itself is setting the null property value by mistake. You'll need to upgrade to ActiveMQ Artemis 2.21.0 once it is available as it will contain the fixes for ARTEMIS-3677 and ARTEMIS-3696. It just passed the release vote so it should be available on the website for download in the next few days. To be clear, the only problem here is with browsing the messages. You should be able to consume the message no problem.

When you push a message to the queue via the web console the core protocol is used (i.e. not STOMP) which is why you can browse successfully.

Your understanding about the semantics of scheduled messages with a last-value queue is correct. When a message is scheduled it is not technically on the queue yet. It is not put onto the queue until the scheduled time arrives at which point last-value queue semantics are enforced.

Short of implementing a new feature I don't see how you can implement your desired behavior in any kind of automatic way. My recommendation at this point would be to use the management API (i.e. QueueControl) to manually remove the "old" scheduled message before you send the "new" scheduled message. You can use one of the removeMessage methods for this as they will work on scheduled messages and non-scheduled messages alike.

The broker is logging this WARN message (and not deleting the queue) because the queue you are trying to delete has consumers on it just as the WARN message indicates:

Cannot delete queue...it has consumers

You can avoid this either by not deleting the queue or removing all the consumers from that queue before deleting it.

In general it's not a good idea for clients to delete queues on the broker since queues are shared resources and may be used by other clients.

I believe the problem is that you need reconnectAttempts > 0 in your URL (e.g. reconnectAttempts=25). The default value for reconnectAttempts is 0.

Also, if you didn't receive a topology update when you connected you'd see an ActiveMQConnectionTimedOutException with a message like this:

What you are seeing is the expected behavior. The key thing to keep in mind here is that you're leveraging wildcard routing and not wildcard consuming. With wildcard routing messages are not only routed to the queues of the address where the message is explicitly sent but also to any queues on matching wildcard addresses. Each queue to which the message is routed has its own copy of the message.

Wildcard routing was implemented with multicast (i.e. pub/sub) use-cases in mind (e.g. hierarchical topics), but there are a few options if you want to use it with anycast:

• Accept the semantics as-is.
• Create the address test.A without a queue, e.g.:

The ActiveMQ plugin shipped with Hawtio is for the ActiveMQ "Classic" broker, not ActiveMQ Artemis. Therefore, it won't detect the embedded instance of ActiveMQ Artemis.

ActiveMQ Artemis itself has a Hawtio plugin consisting of three parts:

1. artemis-console (rename as console.war)
2. artemis-plugin (rename as artemis-plugin.war)
3. activemq-branding (rename as activemq-branding.war)

You could download those war files and deploy them in your web application server (assuming you have one). I've done this on Wildfly 24 and it worked fine once I relaxed security on the remote ActiveMQ Artemis instance (allowing "guest" users and disabling CORS in jolokia-access.xml). Of course, in production you'll want to sort out the security issues, but this should get you moving in the right direction.

There's a handful of problems with your configuration.

• If you want to use both time & size based rotation you need to use org.jboss.logmanager.handlers.PeriodicSizeRotatingFileHandler. Currently you're using org.jboss.logmanager.handlers.PeriodicRotatingFileHandler which will only rotate based on time.
• You're formatting your rotation config properties incorrectly. You're using - characters when you should be using camel case like the rest of the properties. I believe this is because you're reading the documentation from JBoss EAP which has a slightly different configuration format than the plain properties-based configuration used by ActiveMQ Artemis.
• You aren't specifying the rotation config properties in the properties configuration for the FILE handler.
• You're using the size notation k which isn't supported in the plain properties-based configuration used by ActiveMQ Artemis.

Try using this instead:

This is the only acceptor you have:

The ArtemisCloud container image for ActiveMQ Artemis is designed to run inside a container so the container IP address should be used to access to the console or to other resources.

The container IP address can be obtained by using the command docker inspect or by reading the container log, ie: