ActiveMQ probe
The ActiveMQ probe connects to a message broker over STOMP 1.2 and records every frame it sends and every frame the broker sends back. It can put a message on a queue, read messages from a queue or a topic, or send a request and wait for its reply, and each of those runs as ordinary STOMP frames that appear in the history in the order they were exchanged.
The probe asks for STOMP 1.2 when it connects (accept-version: 1.2), so a broker other than
ActiveMQ that accepts a STOMP 1.2 connection can be probed the same way.
Two modes
Section titled “Two modes”Switch with the Action / Advanced toggle above the editor.
Action mode picks one thing to do and builds the frames for it. A new probe opens in Action mode on Send a message.
Advanced mode is the frame sequence itself, with a WAIT step wherever the probe should listen.
Connection settings
Section titled “Connection settings”| Field | Description |
|---|---|
| Host | Hostname or IP of the broker |
| Port | The broker’s STOMP port (default: 61613) |
| TLS mode | None or TLS |
| Trust self-signed certificates | Shown when TLS is on. Skip certificate validation for this probe. Lab use |
| Virtual host | Sent as the host header of CONNECT. Blank sends the host above. Some brokers route by it |
| Heart-beat | Sent as the heart-beat header of CONNECT, in milliseconds: what the client sends, then what it wants. 0,0 means none and is the default |
| Credential | A Basic credential from the credential store |
The credential travels in the CONNECT frame, its username as the login header and its password
as passcode, and with no credential selected the CONNECT carries no login at all. The exchanges
list and the probe’s history show passcode as ****, along with any other header value equal to
the password. The frame the broker receives is not altered, so the broker’s answer to a refused
login is recorded exactly as it arrived.
Action mode
Section titled “Action mode”| Action | What it sends | Fields |
|---|---|---|
| Connect | CONNECT, then DISCONNECT | none |
| Send a message | SEND with a receipt header, then waits for the receipt | Destination, Content type, Body, Extra headers |
| Receive messages | SUBSCRIBE, waits for the messages, then UNSUBSCRIBE | Destination, Messages to wait for, Wait (ms), Acknowledge |
| Send and receive a reply | SUBSCRIBE to the reply destination, SEND with a reply-to header, waits for the reply, then UNSUBSCRIBE | Destination, Reply destination, Content type, Body, Extra headers, Messages to wait for, Wait (ms), Acknowledge |
Every action ends with a DISCONNECT that asks for a receipt. Destination is the broker’s name
for a queue or a topic, for example /queue/orders or /topic/events.
Send a message waits for the broker’s receipt before it passes, so a green probe means the broker confirmed it accepted the message. Send and receive a reply subscribes to the reply destination before it sends, because a reply published before that subscription exists is delivered to nobody and the probe would report it as a timeout.
Messages to wait for defaults to 1 and Wait (ms) to 5000. Acknowledge sets the ack
mode of the subscription: Automatically (auto) leaves acknowledgment to the broker, while Each
message (client-individual) has the probe send an ACK for every message it receives, and the
field then carries a Modifies target chip.
Advanced mode
Section titled “Advanced mode”The Frames section holds the steps in the order they run. Every step has a Command and an
Enabled checkbox, and a frame step also takes its headers and a body. The commands on offer are
SEND, SUBSCRIBE, UNSUBSCRIBE, WAIT, ACK, NACK, BEGIN, COMMIT, ABORT, DISCONNECT
and CONNECT.
The connection opens when the first step that needs the broker runs, with a CONNECT built from the
connection settings. A CONNECT step of your own, placed first, replaces that one and is sent
exactly as written, which is useful when the connect frame itself is under test. Advanced mode sends no DISCONNECT
unless you add one, and the connection is closed when the steps run out.
Any frame you give a receipt header is expected to be answered with a RECEIPT. Before it finishes,
the probe waits for every receipt still outstanding, and one that never arrives fails the probe.
The WAIT step
Section titled “The WAIT step”A broker delivers a MESSAGE frame for a subscription whenever it has one, so listening is a step of
its own. A WAIT step takes three fields:
| Field | Description |
|---|---|
| Wait for | Messages or Receipts |
| Count | For Messages, how many new MESSAGE frames to wait for (default: 1) |
| Wait (ms) | How long to wait (default: 5000) |
A Messages wait is satisfied once that many messages have arrived since the step began, and a Receipts wait once every receipt asked for so far has arrived. A WAIT that is still unsatisfied when its time runs out fails the probe.
These steps put a message on a queue and read it back:
| Command | Headers |
|---|---|
SUBSCRIBE | id: sub-1, destination: /queue/orders |
SEND | destination: /queue/orders, receipt: order-1 |
WAIT | Messages, count 1 |
UNSUBSCRIBE | id: sub-1 |
Modifies target
Section titled “Modifies target”SEND, ACK, NACK and COMMIT carry a Modifies target chip, in Advanced mode on the step and
in Action mode on the actions that send. A SEND delivers a real message to whoever consumes that
destination, an ACK or a NACK removes or requeues a message somebody else may have been waiting
for, and a COMMIT makes the sends and acknowledgments of a transaction take effect.
What counts as a pass
Section titled “What counts as a pass”The probe passes when the connection worked and all of these hold:
- the broker answered the
CONNECT, - the broker sent no
ERRORframe, - every receipt the probe asked for arrived,
- every WAIT step was satisfied.
STOMP has the broker close the connection after an ERROR frame, so the probe stops at the first one
and reports the frame’s message header as its error.
Response
Section titled “Response”Each send produces a Frames list with one row per frame, marked as sent, received, or a step such
as a WAIT, and a row expands to show the frame’s headers and body. The panel header carries the
server header and the STOMP version the broker reported in CONNECTED, a count of the messages
received, and the transport outcome whenever it is not OK: CONNECT_REFUSED, CONNECT_TIMEOUT,
RESOLVE_FAILED, TIMEOUT, EOF, MALFORMED, PARTIAL or ERROR.
Extractors
Section titled “Extractors”| Extractor | Returns | Expression |
|---|---|---|
STOMP_SUCCESS | "true" when the probe passed | ignored |
STOMP_MESSAGE_COUNT | How many MESSAGE frames arrived. 0 is an answer | ignored |
STOMP_MESSAGE_BODY | The body of a received message | A zero-based index, negative to count from the end. Blank means the last message |
STOMP_MESSAGE_HEADER | One header of a received message | Required. name for the last message, or index|name, for example 0|message-id. When a header repeats, the first value counts |
STOMP_SERVER | What the broker said about itself in CONNECTED | Blank or server for the server header, version for the negotiated STOMP version |
STOMP_ERROR | The message header of the broker’s ERROR frame, followed by its body on the next line when there is one. Blank when there was no ERROR | ignored |
An index out of range, or a message that does not carry the header, returns an empty string rather than failing the step.
See Extractors for the full list.
Chains
Section titled “Chains”An ActiveMQ step works like any other. See chain steps. {{variable}}
placeholders resolve into the host, the virtual host, the destination, the reply destination, the
body and the header values, and in Advanced mode into every frame’s headers and body.
To check that an API publishes the event it should, call the API in an HTTP step, then receive from
the destination it publishes to in an ActiveMQ step and assert on the message with
STOMP_MESSAGE_BODY or STOMP_MESSAGE_HEADER.
Mocking the broker
Section titled “Mocking the broker”Interception rules in a rule set with Also apply to outgoing traffic switched
on are matched against this probe’s frames before they are sent.
A rule matches on the host, the frame command and the destination header, where a destination ending
in * matches as a prefix. A frame a rule matches is answered by the rule and never sent to the
broker, and the exchanges list marks it Mocked.
The rule’s text is read as a complete STOMP frame, so a mock can answer with a MESSAGE or an
ERROR. Blank text answers with a RECEIPT when the frame asked for one, and with nothing when it
did not. The connection opens only
when the first frame that needs the broker runs, so a probe whose frames are all answered by rules
never contacts the broker.