Chapter 7. Network Connections: Protocols

Although AMQP has no notion of topics it is still possible to treat AMQP consumers or receivers as subscriptions rather than just consumers on a queue. By default, the broker treats any receiving link attaching to an address that has only multicast enabled as a subscription. The broker will therefore create a subscription queue for the link. The subscription queue is made durable or non-durable depending on the value of the Terminus Durability, as shown in the following table.

AMQ Broker also supports the qpid-jms client and will respect its use of topics regardless of the prefix used for the address.

The broker supports AMQP SASL Authentication. See Security for more information on how to configure SASL-based authentication on the broker.

There are a couple of limitations to keep in mind when using Stomp with AMQ Broker

When receiving Stomp messages via a JMS consumer or a QueueBrowser, the messages by default will not contain any JMS properties, such as JMSMessageID. Because this may inconvenience clients who want to use an ID, the broker provides a parameter to set a message ID on each incoming Stomp message.

<acceptors>
  <acceptor name="stomp-acceptor">tcp://localhost:61613?protocols=STOMP;stompEnableMessageId=true</acceptor>
  ...
</acceptors>

When the server starts with the above setting, each stomp message sent through this acceptor will have an extra property added. The property key is amq-message-id and the value is a String representation of a long type internal message id prefixed with “STOMP”, like:

amq-message-id : STOMP12345

If stomp-enable-message-id is not specified in the configuration, the default is false.

Stomp clients may send very large bodies of frames which can exceed the size of the brokers server’s internal buffer, causing unexpected errors.

To prevent this situation from happening, set the acceptor’s stompMinLargeMessageSize parameter to an appropriate size. The broker will check the size of the body of each Stomp frame coming from connections established with this acceptor. If the size of the body is equal to or greater than the value of stompMinLargeMessageSize, the message will be persisted as a large message.

<acceptors>
  <acceptor name="stomp-acceptor">tcp://localhost:61613?protocols=STOMP;stompMinLargeMessageSize=10240</acceptor>
  ...
</acceptors>

In the example above, the broker is configured to accept STOMP messages on port 61613. If the acceptor receives a STOMP frame with body larger than or equal to 10240 bytes the broker will persist it as a large message.

When a large message is delivered to a stomp consumer, the broker will automatically handle the conversion from a large message to a normal message, before sending it to the client.If a large message is compressed, the server will uncompressed it before sending it to stomp clients.

The default value of stompMinLargeMessageSize is 102400 bytes.

STOMP clients should always send a DISCONNECT frame before closing their connections, which will allow the server to clear up any server side resources, such as sessions and consumers. However, if STOMP clients exit without sending a DISCONNECT frame, or if they crash, the server will have no way of knowing immediately whether the client is still alive. STOMP connections therefore are configured to have a "Time to Live" (TTL) of 1 minute. The means that the broker will terminate the connection to the STOMP client if the connection has been idle for a minute or more.

<acceptors>
  <acceptor name="stomp-acceptor">tcp://localhost:61613?protocols=STOMP;connectionTtl=20000</acceptor>
  ...
</acceptors>

In the example above, any stomp connection that is created using the acceptor will have its TTL set to 20 seconds.

Overriding the Broker’s Default Time to Live (TTL)

As noted the default TTL for a STOMP connection is 1 minute. You can override this value by adding the connection-ttl-override attribute to the broker configuration.

<configuration ...>
  ...
  <core ...>
    ...
    <connection-ttl-override>30000</connection-ttl-override>
    ...
  </core>
<configuration>

In the example above the default Time to Live (TTL) for a STOMP connection is now 30 seconds, 30000 milliseconds.

Stomp is mainly a text-orientated protocol. To make it simpler to interoperate with JMS, the Stomp implementation checks for presence of the content-length header to decide how to map a Stomp message to JMS.

The same logic applies when mapping a JMS message to Stomp. A Stomp client can check the presence of the content-length header to determine the type of the message body (String or bytes).

See the STOMP specification for more information on message headers.

When sending messages and subscribing, STOMP clients typically include a destination header. Destination names are string values that are mapped to a destination on the server. In AMQ Broker, these destinations are mapped to addresses and queues. See the STOMP specification for more information about the destination frame.

Take for example a Stomp client that sends the following message (headers and body included):

SEND
destination:/my/stomp/queue

hello queue a
^@

In this case, the broker will forward the message to any queues associated with the address /my/stomp/queue.

For example, when a Stomp client sends a message (using a SEND frame), the specified destination is mapped to an address.

It works the same way when the client sends a 'SUBSCRIBE' or 'UNSUBSCRIBE' frame, but in this case AMQ Broker will map the destination to a queue.

SUBSCRIBE
destination: /other/stomp/queue
ack: client

^@

In the preceding example, the broker will map the destination to the queue /other/stomp/queue.