This page contains some additional information regarding Stomp protocol version 1.0 (not contained in the specification):

• Transaction Handling
• Character Encoding
• Ack Modes
• Stomp JMS Bindings

Transaction Handling

Stomp uses named transactions so that many transactions can concurrently occur at the same time.

The client specifies the name and it is unique to that client.

so:

BEGIN
transaction: tx1

^@

then you can ack or send using the transaction

ACK
message: ID:19283:wheeeee:1234
transaction: tx1

^@


SEND
destination: /queue/a
transaction: tx1

hello queue a!
^@

ABORT
transaction: tx1

^@

Would “undo” the ack and send

Note that transactions are only related to sending messages and acknowledgments, so there’s no such concept such as receiving messages in transactions. If you abort the transaction that sent some acks, that doesn’t mean that those messages will marked as undelivered and sent again. It just mean that you should try to process them again in your client and acknowledge them when they are successfully processed.

Character Encoding

We need to acknowledge character encoding and set some expectations. Much of this is taken from suggestions by SER (whom I don’t otherwise know).

First, make header names required to be legal XML element names. This makes a lot of sense.

Second, specify the default encoding is UTF-8. This makes ASCII a nice subset for telnet purposes. Add an encoding attribute to the CONNECT and CONNECTED frames. The server should use the same encoding the client requested on the CONNECT, defaulting to UTF-8 if nothing was specified, but if the client requested an encoding which the server cannot handle, it must send back the encoding it will use to handle the session (assuming it could understand the CONNECT frame, of course =)

Ack Modes

The default message acknowledgement (when the server can consider the message to have been consumed by a client) is to treat it as acknowledged as soon as it is transmitted. An alternate is to require the client to acknowledge the message explicitely. Amongst other things this offers transactional message consumption and prevents flooding the client to the point of a crash and losing a pile of messages.

To handle this the client may specify and ack header in a subscription request. The default is “auto” the alternate value (there may be more later) is “client”. If “client” is used the client must send an ACK frame with the message-id from the message, which may also have a transaction header with an open transaction identifier.

SUBSCRIBE
ack: client
destination: /queue/a

^@

ACK
message-id: ID:12345

Stomp JMS Bindings

When using the Stomp Protocol with StompConnect or a JMS provider there are some additional Stomp headers and semantics which are useful to know. In terms of JMS semantics Stomp supports the same ack modes unless the messages are exchanged within a transaction via BEGIN/COMMIT/ABORT

Standard JMS Message Headers

The following standard JMS Headers are mapped to Stomp as follows; so these headers can be added to a SEND command when sending messages

Subscription headers

You can use an SQL 92 selector whenever you subscribe using the selector header

selector:location = 'London' and sex = 'M'

When subscribing for a topic you can specify the header

no-local:true

This will disable local messages. Namely messages published over the Stomp connection will not be received by this topic subscription.

Durable Topic Subscribers

If you wish to create a durable topic subscriber you will need to do the following

• set the client-id header on the CONNECT to a globally unique String for the Stomp connection
• set the durable-subscriber-name header on the SUBSCRIBE command.

The combination of the client-id and durable-subscriber-name uniquely identifies the durable topic subscription. i.e. after you restart your program and re-subscribe, the Broker will know which messages you need that were published while you were away