$ guides / activemq / activemq-advisory-topics-overhead ▌

Operations Guides

ActiveMQ advisory topics: hidden destinations consuming resources

List every topic on a busy ActiveMQ Classic broker and count how many start with ActiveMQ.Advisory.. On a broker with a thousand queues, you can easily find a thousand or more advisory topics, each a real destination with its own JMX MBeans, each receiving non-persistent messages for broker events.

This is not a bug. Advisory topics are how the broker publishes internal events: connections opening and closing, consumers and producers starting and stopping, destinations hitting their memory limit, messages expiring. Tools and clients can subscribe to observe the broker. The problem is that the default behavior scales with destination count, not with how much of this information anyone consumes, and the cost is paid in MBean count, heap, GC pressure, and inflated throughput counters.

This article covers what advisory topics are, how to quantify their cost on your broker, and how to reduce or eliminate the overhead without breaking the features that depend on them.

What advisory topics are

Advisory topics are ordinary topics under the ActiveMQ.Advisory.* namespace that the broker creates and publishes to automatically. The broker emits advisory messages for lifecycle events: connection start and stop, consumer and producer start and stop, destination creation, destination memory full (ActiveMQ.Advisory.FULL.*), expired messages, and others. Some advisories are generated for every client and every destination by default; others (slow consumer, message delivered/consumed, and similar) are off by default and only fire when enabled per policy entry.

Two properties matter operationally:

They are real destinations. Each advisory topic appears in JMX like any other topic, with its own MBean and its own enqueue counters. The broker’s own FAQ acknowledges this: those ActiveMQ.Advisory.* entries in your JMX tree are real topics, not metadata.
Advisory messages are non-persistent. They are never written to KahaDB. That keeps them off disk, but they live entirely in broker memory and can be dropped under memory pressure. An advisory stream is not a reliable audit trail; if you need a record of every consumer disconnect, advisories are not it.

How the count multiplies

Advisory topics are generated per event source, and the sources scale with destinations, connections, consumers, and producers:

flowchart TD
  D[Application queues and topics] --> E[Broker lifecycle events]
  C[Client connections, consumers, producers] --> E
  E --> A[ActiveMQ.Advisory.* topics]
  A --> M[One MBean set per advisory destination]
  A --> T[Messages counted in TotalEnqueueCount]
  M --> H[Heap usage and GC pressure]
  T --> I[Inflated throughput metrics]

Each destination on the broker costs multiple MBeans, and advisory destinations are destinations. With a thousand queues, you have over a thousand advisory topics by default, and the MBean tree roughly doubles. The consequences:

Heap and GC pressure. MBean metadata, destination state, and subscription bookkeeping all live on the JVM heap. Destination count grows, heap grows, GC frequency climbs, JMX queries slow down, and eventually the broker degrades even though application traffic is unchanged.
JMX slowness. JMX queries serialize MBeans. On a broker with tens of thousands of destinations (application plus advisory), a simple query can take seconds, and high-frequency polling from your monitoring stack becomes a load of its own.
Inflated metrics. TotalEnqueueCount on the broker MBean counts every message the broker accepts, including advisory messages. If you treat broker-level enqueue rate as application throughput, you are measuring event noise along with business traffic.

Where this shows up in production

Three recurring scenarios:

Destination-heavy brokers. Teams using dynamic destination creation (per-tenant queues, per-request reply topics) end up with thousands of destinations, each spawning advisory traffic for consumer and producer events. Destination count, MBean count, and heap climb together, and the root cause is not obvious from application metrics.
High-churn clients. Clients that connect and disconnect frequently, or create short-lived consumers (common with poorly pooled consumers), generate a steady stream of advisory messages. Each connect/disconnect and consumer start/stop is a published message on a real topic.
Monitoring confusion. An operator graphs TotalEnqueueCount to track business message volume and sees traffic that does not match what producers report sending. The delta is advisory messages. Filter by destination for accurate application throughput.

None of these is an incident by itself. They are a quiet tax that shows up as “the broker needs more heap than the message volume justifies,” “JMX is slow,” or “the numbers do not add up.”

Measuring the overhead on your broker

All read-only checks. Run them before changing anything.

# Count total topics and advisory topics via Jolokia
curl -s -u admin:admin \
  'http://localhost:8161/api/jolokia/read/org.apache.activemq:type=Broker,brokerName=localhost/Topics' \
  | python3 -c "
import json, sys
topics = json.load(sys.stdin)['value']
adv = [t for t in topics if 'Advisory' in str(t)]
print('total topics:', len(topics))
print('advisory topics:', len(adv))
"

# Count queues for comparison
curl -s -u admin:admin \
  'http://localhost:8161/api/jolokia/read/org.apache.activemq:type=Broker,brokerName=localhost/Queues' \
  | python3 -c "import json,sys; print('queues:', len(json.load(sys.stdin)['value']))"

If advisory topics are a large fraction of total topics, or exceed your queue count, you are carrying meaningful overhead.

# Broker-level enqueue counter: includes advisory traffic
curl -s -u admin:admin \
  'http://localhost:8161/api/jolokia/read/org.apache.activemq:type=Broker,brokerName=localhost/TotalEnqueueCount'

# JVM heap for correlation
curl -s -u admin:admin \
  'http://localhost:8161/api/jolokia/read/java.lang:type=Memory/HeapMemoryUsage'

Take two TotalEnqueueCount readings a minute apart and compare the derived rate with the summed enqueue rates of your application destinations. The gap is internal traffic, most of it advisory. Also watch JMX query latency itself: if the topic-listing call above takes noticeable time, your MBean tree is already large.

Reducing the overhead

Three levers, from most to least aggressive. Check one dependency before touching any of them.

The dependency to check first: network connectors

Network connectors subscribe to advisory messages. Consumer demand propagates between brokers in a Network of Brokers through advisories; if advisories are suppressed or filtered, bridges will not forward messages correctly. If you run a NoB topology and disable advisory support, you must statically configure destination inclusion and exclusion on your connectors, or demand forwarding breaks. The official documentation is blunt: in the absence of advisories, a network must be statically configured. On a standalone broker with no network connectors, no such dependency exists.

Also note: if you lock down destination creation with authorization policies, clients need permission to create ActiveMQ.Advisory destinations for features that emit advisories to work. Restricting that ACL can silently break features you did not intend to disable.

Disable advisory support on the broker

Set advisorySupport="false" on the <broker> element in activemq.xml:

<broker xmlns="http://activemq.apache.org/schema/core"
        brokerName="localhost"
        advisorySupport="false">

This stops the broker from creating advisory topics and publishing advisory messages at all. Use it when nothing consumes advisories: no network connectors relying on demand forwarding, no monitoring clients subscribed to ActiveMQ.Advisory.*, no dependence on advisory-publishing features such as watching ActiveMQ.Advisory.FULL.* for flow-control events. This requires a broker restart.

Disable client-side advisory subscriptions

OpenWire clients automatically subscribe to certain advisories (temp destination deletion events, for example). Even with broker-side advisories reduced, clients may still create advisory consumers. Disable this on the connection URL:

tcp://broker:61616?jms.watchTopicAdvisories=false

or via ActiveMQConnectionFactory.setWatchTopicAdvisories(false). Broker-side and client-side settings are independent; if you want advisory traffic fully gone, set both. Disabling client-side advisory watching changes how clients learn about temp destination deletion, so verify request/reply patterns that depend on it.

Suppress advisory MBeans while keeping advisories

If you need advisories (network connectors, tooling) but the MBean explosion is the problem, ActiveMQ 5.12.0 and later can exclude advisory destinations from MBean registration via suppressMBean on the management context:

<managementContext suppressMBean="destinationName=ActiveMQ.Advisory.*"/>

The advisory topics still exist and still carry messages, but they no longer inflate the JMX tree, which removes most of the heap, GC, and JMX-latency cost. This is the right middle ground for large NoB deployments.

Signals to watch in production

Signal	Why it matters	Warning sign
Advisory topic count vs application destination count	Direct measure of advisory overhead	Advisory topics comparable to or exceeding queues plus application topics
Total destination count	Each destination costs MBeans and heap	Continuous growth, or count far above expected application design
Broker `TotalEnqueueCount` vs summed per-destination enqueues	Isolates internal (advisory) traffic from business traffic	A persistent gap that scales with client churn, not business load
JVM heap usage after GC	MBean and destination metadata live on heap	Heap-after-GC trending up while message volume is flat
GC pause duration and frequency	MBean explosion adds GC pressure	Rising GC frequency correlating with destination count growth
JMX query latency	Large MBean trees make monitoring expensive	Destination-listing queries taking seconds

How Netdata helps

Destination count and MBean growth over time. Netdata’s JMX collection tracks broker-level metrics continuously, so slow destination and MBean creep is visible as a trend rather than discovered during a heap incident.
Enqueue metric decomposition. Graphing TotalEnqueueCount alongside per-destination enqueue rates makes the advisory share of broker traffic visible, so application throughput dashboards stop lying.
Heap and GC correlation. Overlaying JVM heap-after-GC and GC pause metrics against destination count shows whether memory pressure tracks message volume or metadata growth. Flat traffic with rising heap points at advisory/MBean overhead or a destination leak.
JMX health of the broker itself. On brokers with large MBean trees, collection latency and failed JMX reads are themselves a signal that the tree is too big.
Alerting on the trend, not the snapshot. Destination count doubling over weeks is a planning problem; Netdata’s per-second history catches slow growth before it becomes a GC death spiral.