TAFJ JMS Paging Store Growing Fast

What Artemis paging actually means

ActiveMQ Artemis applies paging at the address level. When the configured address memory threshold is reached and the address policy permits paging, the address enters page mode and further messages are written to broker-managed page files. Paging does not simply mean that an arbitrary set of messages was moved from memory to disk.

Page files remain part of the broker's persistent state until Artemis can depage and process the referenced messages. A growing paging directory therefore needs to be correlated with address policy, queue depth, consumer progress, producer rate, and available storage.

First evidence to capture

1. Address and queue names, queue depth, delivering count, and message-count trend.
2. Consumer count, consumer connection state, and last confirmed consumption time.
3. Producer rate compared with acknowledgement or consumption rate.
4. Paging directory size and filesystem free-space trend at timestamped intervals.
5. Broker warnings, address settings, paging thresholds, and configured page size.
6. Expiry address, dead-letter address, redelivery count, and retry-delay evidence.
7. Recent deployments, outages, network changes, or downstream slowdowns.

Use the management interface and commands approved for the installed Artemis and application-server version. Object names, commands, and paths vary by deployment.

Distinguish the common patterns

Temporary producer burst

Queue depth and page storage rise, active consumers continue acknowledging messages, and both measures later fall. The key evidence is continued forward progress and enough disk headroom for the expected burst.

Slow consumer

Consumers exist but acknowledgements advance more slowly than production. Check downstream latency, database waits, transaction duration, thread pressure, and consumer-side errors before changing the broker.

No active consumer

Messages accumulate while consumer count or delivery activity is absent. Capture the connection, application, authentication, selector, and listener evidence. Do not jump directly to a restart: first determine whether the original consumer stopped after an uncertain transaction and whether reconnecting can redeliver or duplicate work.

Repeated redelivery

Delivery attempts rise but messages return to the queue because processing is rolled back or negatively acknowledged. This differs from expiry. Redelivery policy controls retry behaviour; expiry controls when a message is considered expired and, when configured, routed to an expiry address.

Safe containment sequence

1. Preserve queue, consumer, broker, application, and disk evidence.
2. Identify message ownership and whether any delivery outcome is uncertain.
3. Assess duplicate, redelivery, ordering, and downstream business impact.
4. Reduce producer rate only through an approved upstream control when disk risk requires it.
5. Add storage or protect capacity through the platform runbook when paging threatens the filesystem.
6. Recover or reconnect the consumer only through the approved service procedure after the uncertainty assessment.

What a restart proves—and what it does not

A controlled restart may restore a failed consumer or clear a transient runtime fault, but it does not explain why paging began. It can also trigger redelivery, reconnect producers, or change the evidence available for diagnosis. Record the pre-restart state, confirm ownership, and understand duplicate risk before using the locally approved restart procedure.

When to involve vendor or product support

• Page files remain after queues appear drained and the broker cannot depage them.
• Broker logs report page corruption, journal inconsistency, or repeated I/O failures.
• The supported recovery procedure is unclear for the installed Artemis version.
• Disk exhaustion is imminent and containment would alter or discard message state.
• Message ownership cannot be reconciled safely across T24 and downstream systems.

Provide version details, address settings, queue and consumer snapshots, disk trends, the first relevant error, and a redacted timeline. The general incident evidence guide is available in five things to check before escalating a T24 incident.

Related reading