Sun GlassFish Message Queue 4.4 Administration Guide

STOMP Protocol Features and the STOMP Bridge

The STOMP bridge supports the full STOMP protocol, including all additional STOMP headers for the STOMP JMS bindings, as listed at http://stomp.codehaus.org/Stomp+JMS.

The following table clarifies how the STOMP bridge handles certain command and header combinations that might be otherwise be subject to multiple interpretations.

Table 12–11 STOMP Bridge Handling of Selected Command/Header Combinations

STOMP Frame Command 

STOMP Frame Header 

Handling by the STOMP Bridge 

CONNECT

login

passcode

The STOMP bridge requires these headers to be specified; otherwise, it returns an ERROR frame.

SEND

SUBSCRIBE

UNSUBSCRIBE

MESSAGE

destination

MQ STOMP bridge interprets prefixes in destination header values as follows:

  • /queue/: the prefix is followed by the name of a Queue

  • /topic/: the prefix is followed by the name of a Topic

  • /temp-queue/: the prefix is followed by the name of a TemporaryQueue

  • /temp-topic/: the prefix is followed by the name of a TemporaryTopic

Note that the following two prefixes are reserved to be used only for send reply messages to a MESSAGE frame's replyto destination, and should only be used in the same CONNECT session in which the MESSAGE is received.

  • /temp-queue/temporary_destination://queue/

  • /temp-topic/temporary_destination://topic/

SEND

expires

priority

persistent

When these headers are not specified for SEND, the message will be sent with the same default values as for a Message Queue Java client.

SEND

user specific headers 

On SEND, a user can specify additional headers beyond the ones specified in the STOMP protocol and STOMP JMS Bindings. These headers are transformed to String properties of the converted JMS message. Therefore, the keys for these headers must be valid JMS property names. If any are not, and a custom message transformer is specified for STOMP bridge, the invalid ones are passed in the properties argument to the transformer's transform() method.

SUBSCRIBE

selector

Supported as described in the STOMP JMS Bindings on SUBSCRIBE.

SUBSCRIBE

id

A STOMP client should always specify an id header for SUBSCRIBE. If no "id" header is specified, the STOMP bridge assigns it a default value of /subscription-to/STOMP-destination-name.

All SUBSCRIBE id values must be unique in the scope of the STOMP client connection to the STOMP bridge; otherwise, an ERROR frame will be returned.

SUBSCRIBE

transaction

For a STOMP subscription to receive messages in a transaction, the SUBSCRIBE frame must specify a transaction header with a transaction identifier whose transaction state is started. If the transaction does not exist, an ERROR frame is returned. After the transaction completes (using either COMMIT or ABORT), message delivery to the transacted subscription is paused until the next transaction BEGIN.

ABORT

transaction

For transacted subscriptions, aborting a transaction will cause the STOMP bridge to stop message delivery to all transacted subscriptions in the CONNECT session. Then, upon the next BEGIN, the STOMP bridge restarts the message delivery sequence to all the transacted subscriptions in the CONNECT session, including all unconsumed messages that had been previously delivered.

SUBSCRIBE

ack

For STOMP ack:auto (the default), a subscribed message is considered acknowledged as soon as it is sent to the STOMP client.

UNSUBSCRIBE

durable-subscriber-name

Unsubscribes a durable subscription, with these provisions: 

  • destination and id headers, if specfied, are ignored.

  • An ERROR frame is returned if the connection (CONNECT) has no client-id.

If an active subscriber with the durable name exists on the connection, it is first closed, and then the durable subscriber is unsubscribed.  

BEGIN

transaction

Transactions are at STOMP CONNECT session level. Nested transactions are not supported. On attempts to start a nested transaction, an ERROR frame is returned.

The transaction identifier will also be used for SUBSCRIBE frame to create a transacted subscription.

ACK

subscription

ACK should always specify a subscription header specifying the subscription id that the message to be acked was delivered to.

If a subcriber id is not specified, the STOMP bridge default subscription id prefix is used to find the first matching subscription id with the prefix to ack the message. 

If the subscription for the specified subscription id was not created as transacted, and a transaction header is specified for the ACK, an ERROR frame is returned;

ACK on a message ID, if found, will ACK all earlier messages delivered to the subscription in addition to the message with the given message ID.

ACK

transaction

For transacted subscription, an ACK for a message ID automatically ACKs all ealier messages sent to the transacted subscription in addition to the message with the given message ID. For transacted subscription, a message is considered consumed only when it is explicitly or implicitly ACKed in a transaction and there is a subsequent successful COMMIT on that transaction. If the transaction header is not specified but the subscription header is specified and the subscription is a transacted subscription, the message is ACKed in the current transaction if there is a current transaction. If there is no current transaction, an ERROR frame is returned.

MESSAGE

ERROR

content-length

The STOMP bridge always sets the content-length header for MESSAGE and ERROR frames sent to STOMP clients.

SEND

MESSAGE

reply-to

The STOMP bridge permits SEND from different STOMP CONNECT sessions as well as from the same CONNECT session to send reply messages to a STOMP reply-to header of temporary destination:

  • In the same CONNECT session, when SUBSCRIBE and SEND reply, use the same temporary destination string that is used in the SEND's reply-to header.

  • In a different CONNECT session, upon receiving a MESSAGE with a reply-to header of a temporary destination, use the same temporary destination string in the MESSAGE's reply-to header to SEND a reply to the reply-to temporary destination. This technique can also be used for sending the reply message when in the same CONNECT session.