JMS consumer
Description
JMS consumer reads messages from a JMS queue or topic and turns each into a row.
It works with any JMS 3.0 provider. Apache ActiveMQ Artemis works with no extra setup because its client ships with the transform; other brokers — ActiveMQ "Classic", RabbitMQ through its JMS client, IBM MQ — are reached by adding their client jar and using JNDI mode on the JMS connection.
Options
| Option | Description |
|---|---|
Transform name | Unique name of the transform in the pipeline. |
JMS connection | The JMS connection metadata object to use. |
Destination type |
|
Queue / topic name | Name of the destination. Supports variables. |
Message selector | Optional JMS selector expression, evaluated by the broker so unwanted messages are never delivered. For example |
Durable subscription name | Topics only. Makes the subscription durable, so messages published while the pipeline is not running are still delivered. The JMS specification requires a client id on the connection for this. |
Use a JMS transaction | Commit each message in a JMS transaction instead of acknowledging it individually. |
Maximum messages | Stop after this many messages. |
Receive timeout (ms) | How long to wait for a message before concluding the destination is drained — see When the transform stops. |
Message body field | Field to put the message body in. Leave empty to omit it. |
Correlation id field | Field for the JMS correlation id. Leave empty to omit it. |
Destination field | Field for the destination the message came from. Leave empty to omit it. |
Message id field | Field for the broker-assigned message id. Leave empty to omit it. |
Timestamp field | Field for the broker timestamp, as a Date. Leave empty to omit it. |
Every output field is optional: naming a field adds it to the row, leaving it empty keeps it out. Fields appear in the row in the order listed above.
When the transform stops
Consumption ends on whichever comes first:
-
the Maximum messages count is reached,
-
no message arrives within Receive timeout, or
-
the pipeline is stopped.
The timeout is what makes this a batch-friendly transform: it drains what is on the destination and finishes, rather than blocking a pipeline forever. To poll continuously, schedule the pipeline to run repeatedly rather than raising the timeout.
Acknowledgement and message loss
The transform uses CLIENT_ACKNOWLEDGE, and acknowledges each message only after its row has been passed downstream. If the pipeline fails partway, unacknowledged messages stay on the broker and are redelivered.
AUTO_ACKNOWLEDGE is deliberately not used: it confirms the message on receipt, so a failure later in the pipeline would lose it silently.
Acknowledging after putRow guarantees the row was handed to the next transform, not that the pipeline finished with it. For end-to-end exactly-once behaviour you still need an idempotent target. |