STOMP Spec deviation

Details xtomp's implementation of the STOMP specification.

xtomp implements STOMP1.2

The spec. has some items that are recommended or implied. STOMP specifically avoids defining how brokers should be implemented or behave. xtomp behaves as a message broker would be expected to behave for message such as CONNECT, SUBSCRIBE, SEND, UNSUBSCRIBE, DISCONNECT.

version negotiation

xtomp does not perform version negotiation and will not downgrade or change behaviour if a different version is specified during CONNECT.

content-type

Despite RECOMMENDS xtomp does not explicitly set content-type on server message responses i.e. CONNECTED, RECIEPT, ERROR
The following is presumed where absent.

content-type:text/plain;charset=utf-8

content-length

Despite RECOMMENDS xtomp does not set content-length on CONNECTED, RECIEPT or ERROR.
xtomp RECOMMENDS not setting content-length for commands as well, every byte is read anyway.
Clients should only set content-length if they plan to send a 0 byte in the message (i.e. sending binary data) reason is that its impossible to recover from an error if expecting zeros since we cant determine the end of frame so client is disconnected on parse errors.

pipelining

CONNECT or STOMP frames must not be pipelined. i.e. Send the CONNECT and wait for a response before trying to SUBSCRIBE.

\r

Use of \r\n is discouraged. Use \r\n for preference as in the STOMP 1.0 specification.

whitespace in headers

Always 1.2 style, i.e. never trim, whitespace in headers that xtomp neads to read will cause errors.

IDs

Subscription id should be incrementing positive integers starting at 0.

Message id should be as well.

Transactions not implemented

xtomp has no notion of transactions or message batches.

Limits

STOMP 1.2 allows for brokers to limit size of certain features such as number of headers, size of messages, concurrent subscribers. The errors page indicates error messages xtomp returns when those limits are hit. Some limits are compile time limits and some are configurable in xtomp.conf.

Persistence

xtomp is an in memory broker, messages are not saved to disk, parts of the STOMP spec imply durability but xtomp 0.1 does not implement this.

ACK always auto for topics

xtomp only supports ACK client when subscribing to queues.

Topics are implicitly ACK auto no matter what the client sends in the subscription, xtomp will not fail if client is sent and will not fail ACK messages that are sent that it does not require.
This approach allows using xtomp as a test replacement for STOMP servers that do require ACKs without changing the client code. Not supporting client for topics makes little difference while all messages are in memory and there are no persistent subscriptions. In-flight messages may be lost if the xtomp server crashes and should be resent by publishers.
There is currently no way for subscribers to pickup or missed messages unless the publisher resends them.
memq supports auto & client ACK and NACK.
Using idempotent/DUPS_OK type subscribers is recommended, i.e. clients should ignore messages sent twice, future xtomp versions may implement this in the broker itself.