Many teams use ActiveMQ. In this blog, we break down ActiveMQ queues vs. ActiveMQ topics. And we talk about some of the problems with the ActiveMQ dynamic queue.
ActiveMQ queue is a pipeline of messages where a message comes in and goes to just one subscriber. ActiveMQ topic is a pipeline of messages where a message comes in and goes to every subscriber.
Both ActiveMQ queue and ActiveMQ topic are places where messages are sent. The difference is in who receives the message.
The ActiveMQ queue is a dynamic queue. Keep reading to learn how it works.
By default, ActiveMQ automatically creates a destination inside the broker any time a client either consumes from or produces to a destination. Although this functionality is useful for many implementations, when you have a large number of brokers and clients it can lead to accidents. If a destination is misspelled, or, worse, a client connects to the wrong broker instance, ActiveMQ will happily create the destination even though it’s undesired.
In systems that use publish/subscribe topics, this can lead to message loss. If a topic-producing client connects to a broker with no consumers, i.e. the wrong broker, and starts publishing messages, all of those messages will be discarded, per Java Message Service (JMS) topic behavior. If an extremely productive producer starts blasting the wrong message broker with messages, it can become overwhelmed and lead to downtime.
In a traffic-partitioned broker network, you may have hundreds or even thousands of broker nodes. Keeping a strict destination inventory for clients becomes increasingly important as the complexity of your broker and client network increases. So that makes us ask – is ActiveMQ’s dynamic queue creation feature working for you? Or is the feature is more trouble than it’s worth.
Unfortunately, ActiveMQ doesn’t provide a simple switch to make this possible.
Instead, you must make use of ActiveMQ’s JAAS-based authorization feature, and disallow clients the ability to create destinations. Authorization in ActiveMQ is based on roles and allowed operations. A role can be mapped to one of three actions, “read,” “write,” or “admin.” It is the “admin” operation that allows a client to create or remove a destination from the broker instance.
For implementations which already authenticate clients using JAAS, an administrator just has to restrict the “admin” operation to a role which isn’t used by the client. If you’re not authenticating your clients, which means they are authenticating as the “anonymous” role, so you just need to restrict the “admin” operation to a role other than “anonymous” to restrict their ability to create destinations.
You can do both of these by setting an AuthorizationPolicy against all queues and topics, and, if you are authenticating your clients, by assigning the client’s group to a role that does not allow the “admin” operation on the specified destinations.
The destination policy will look something like:
<jaasAuthenticationPlugin configuration="activemq-domain" />
<authorizationEntry queue=">" admin="admins" />
<authorizationEntry topic=">" admin="admins" />
This configuration will tell the broker that only users with the “admins” role, as specified in conf/groups.properties, are allowed to create or destroy destinations within the broker. As long as the authenticating (or anonymous) client does not belong to the “admins” role, the clients will not be able to automatically create destinations in the broker, and will receive an exception if they attempt to Produce or Consume from a destination which doesn’t exist.
Note: This restriction applies only to clients that are authenticating into the broker, and not the Web Console or CLI, which manage their authentication through a different mechanism than the JAAS configuration. So even with this restriction in place, users will still be able to create and destroy destinations using the admin tools.
Once that change has been made, you’ll also want to configure the broker to create the desired destinations during broker startup, since the clients will no longer be able to create them on-demand. This will allow strict control over exactly which destinations exist inside the broker.
To do this, you’ll want to configure “startup destinations.” This can be done via the broker’s activemq.xml configuration file. The element supports a sub-entity called which you can use to create these:
This configuration would create two destinations in the broker on broker startup, a queue called “MyStartupQueue,” and a topic called “MyStartupTopic.” When the broker starts, it will automatically create these destinations if they do not already exist. As mentioned, you can also create destinations from within the Web Console and/or the CLI.
By combining the JAAS authentication context above, and creating startup destinations, you can have guaranteed strict controls over what destinations exist within the broker, and prevent clients from creating arbitrary ones. Though not as straightforward of a solution as it could be, it does effectively solve the problem, should your business decide to turn off ActiveMQ’s dynamic queue creation feature.
ActiveMQ is a great messaging solution. But to get the most out of it, you might need some help. Luckily, OpenLogic experts are ready to help you get the most out of ActiveMQ.
Get in touch with our experts today to learn how we can help you be successful with ActiveMQ.
Talk to an Expert
Chief Architect, Perforce Software
Justin has over 20 years of experience working in various software roles. He is an outspoken free software evangelist, delivering enterprise solutions, technical leadership, and community education on databases, architectures, and integration projects.