Consumers and producers

Both belong to a session, which belongs to a connection. These two screens answer the questions the queue depth cannot: who is taking messages, who is sending them, and why a queue that looks staffed is not moving.

Consumers

Status is the column that explains a stuck queue

Artemis reports Orphaned for a consumer whose session has gone but whose registration survived. It will never take another message — and it still occupies a slot on an exclusive queue or one with a max-consumers limit.

A queue showing "1 consumer" and a depth that never falls is explained by that one word, and by nothing else on the screen.

A selector is the other explanation

A consumer with a selector takes only what matches it. So a full queue with a healthy consumer count is not a contradiction; it is a queue whose messages match nobody's selector. A consumer without one reads everything rather than showing an empty cell.

In flight, and what closing costs

In flight counts messages handed to this consumer and not yet acknowledged, with their size where the broker reports it. Closing the consumer returns them to the queue — the tooltip says so where the number is, because that is the question anyone about to close one is actually asking.

The confirmation then repeats it with this consumer's own number, and adds the part that costs something: those messages return for redelivery, and a redelivery counts against a delivery limit if the queue has one. A consumer holding nothing undelivered is told that instead, in as many words — there is no figure to report and no consequence to warn about.

Either way its session and connection stay open, so a client that keeps consuming will simply open another consumer. Closing one is not a way to stop a client.

Alongside: what it is consuming from, its client, messages delivered, and its status. Acknowledged and Last delivery are off by default and turned on from Columns. A consumer that has never taken a message shows a dash under Last delivery, and hovering it says so. The list opens with the most messages in flight first.

Close asks for a reason, and appears only for someone allowed to change this broker — not in a read-only environment or on a read-only connection. If the broker finds the consumer already gone, the console says so rather than reporting a close it did not make.

Eight fields cannot be filtered, and one of them explains the whole screen

Artemis's consumer view declares eight fields its filter predicate never implements: status, queueType, browseOnly, sequentialId, creationTime, lastDeliveredTime, lastAcknowledgedTime — and connection. A filter on any of them returns every consumer while appearing to work, so none of them is offered.

connection being among them is why a consumer is reached through its session. There is no way to ask the broker for one connection's consumers directly; a session can be filtered, and a consumer belongs to a session, so that is the path the console takes. What looks like a navigation preference is the only route the broker leaves open.

The broker can order the list by five of the eight — status, queueType and the three timestamps. This screen sorts by queue, messages in flight, delivered or acknowledged, and also by Last delivery and Status, which the broker orders although it cannot filter them.

Producers

Read-only, because the broker has no close for a producer

Artemis closes connections, sessions and consumers. It has no operation that closes a producer.

Its session is the handle, so the row's action opens the sessions list rather than offering a Close whose effect this console would have to approximate.

Two things that look like defects and are not

The address can be the session's, not the producer's. For a producer created without a destination — the normal case for an anonymous JMS producer — the broker falls back to the session's default address, and that is what the column shows.

Sent and Volume cannot be sorted — or filtered. name, msgSent, msgSizeSent and lastProducedMessageID are reported by the producer view and implemented by neither its filter predicate nor its sort. The broker will tell you a producer's volume and can do nothing else with it. So those columns carry no sort control, because a header arrow that errors is worse than one that is absent.

That makes three states rather than two, and the console tracks all three: a field can be filterable and sortable, sortable only — a session's user is reported, cannot be filtered, and can order the list — or neither, like msgSent here. Getting it wrong in either direction is a real failure: offering an unsupported filter returns a silently wrong list, and refusing a supported sort breaks a working column.

Alongside those: the client and when it opened — newest first. Last message, the broker's id for the last message the producer sent, is off by default and turned on from Columns.