Queues and subscriptions

Queues are bound under an address. Each row names the queue on top and the address it is bound under beneath it, because a queue name only means something inside that scope.

Three columns that a depth cannot replace

The depth tells you how much is waiting. These tell you why, and they are in the default column set rather than behind a picker because without them the depth is unreadable.

• Delivering — dispatched to a consumer and not yet acknowledged. A depth that will not fall with zero consumers is a different problem from one with a hundred messages in flight, and only this column separates them. The queue's In flight tab lists those messages and the consumer holding each.
• Scheduled — held until a delivery time. Scheduled messages do not appear in a browse, so a queue can look empty while holding thousands of them. This column is the first sign; the queue's own Scheduled tab lists them, and can deliver them now — see Scheduled, in-flight and grouped messages.
• Filter — the queue takes only what matches. A queue holding less than its address routed is explained by this column or by the address's routing type, and by nothing else.

Badges that change what you should do

paused — delivery is suspended. Messages keep arriving; nothing leaves until it is resumed. A paused queue with a rising depth is working exactly as configured.

Durable: No — this queue and its messages do not survive a broker restart. It is called out rather than left as a neutral value, because it changes what a restart costs.

internal — created by the broker for its own use rather than by an application.

The broker sorts and pages, not the table

The list is one page of what may be thousands of queues. Sorting the rows on screen would sort a slice and call it an order, so the sort is sent to Artemis and the table renders the order it was given.

Sortable columns: queue name, messages, consumers, delivering and scheduled. Filtering works the same way and follows the same per-field operator rules described on Addresses.

Subscriptions are multicast queues — there is no other object

If you came looking for durable subscriptions, they are here.

Artemis has no subscription object. At 2.44.0 there is no topic control and no subscription operation anywhere in its management API: a subscription is a multicast queue, durable or not.

So the Subscriptions entry opens this same screen with the broker's own routingType = MULTICAST filter applied. Every row it returns is a subscription, filtered by Artemis rather than sliced here. The Routing column disappears — every cell would read the same word — and Durable becomes the column that differentiates, because a non-durable subscription is still a subscription.

There is no filter control on that route. The one clause Artemis's query carries is already spent on the routing type, so a second control could only replace it and take the screen off its own subject. Show all queues returns you to the unfiltered list.

The broker's own multicast queues — its cluster and notification queues, which are not subscriptions — are hidden from each page by default. The line above the table says how many were hidden, and Show them brings them back; the pager still counts what the broker returned.

Creating a queue

New queue takes the address it binds under, the routing type — which must be one the address carries — a name that is unique across the broker, not just within the address, and an optional JMS selector — messages published from this console carry String properties only, so a numeric comparison such as priority > 5 will not match them, and the dialog says so. Classification is recorded on the audit trail with the queue, pre-selected from the environment's default. Two checkboxes follow: durable (the queue and its messages survive a broker restart), and create the address too, if it does not exist yet.

The dialog opens by saying what cannot be undone: a queue is bound under an address with one routing type, and neither can be changed afterwards — changing either means deleting the queue and creating it again.

New queue appears only for someone allowed to change this broker, and not in a read-only environment or on a read-only connection. Creating a queue is a write and is recorded in the audit trail.

Opening a queue

A row opens the queue detail, which is where the depth becomes a list of actual messages and where the per-queue history lives.