Please see the Stomp site for more details
Enabling the ActiveMQ Broker for Stomp
Its very easy to enable ActiveMQ for Stomp. Just add a connector to the broker using the stomp URL.
To see a full example, try this XML. If you save that XML as foo.xml then you can run stomp via the command line as
For more help see Run Broker.
Stomp implementation fully supports an ActiveMQ security mechanism. This means that the
Enabling Stomp over NIO
For better scalability (and performance) you might want to run Stomp protocol over NIO transport. To do that just use
Enabling Stomp over SSL
It's easy to configure ActiveMQ to use Stomp over SSL connection. All you have to do is use
Heart-beat grace periods
The STOMP protocol (version 1.1 or greater) defines the concept of heart beats as a method by which a client and broker can determine the health of the underlying TCP connection between them.
ActiveMQ offers support for STOMP defined heart beating provided the client is using version 1.1 (or greater) of the protocol. Prior to ActiveMQ 5.9.0, however, the enforcement of the 'read' heart-beat timeout (that is, a heart-beat sent from the client to the broker) was strict. In other words, the broker was intolerant of late arriving read heart-beats from the client. This resulted in the broker concluding that the client was no longer present causing it to close its side of the client's connection when the client failed to honor it's configured heart-beat settings.
As of version 5.9.0 the timeout enforcement for read heart-beats is now configurable via a new transport option,
This multiplier is used to calculate the effective read heart-beat timeout the broker will enforce for each client's connection. The multiplier is applied to the read-timeout interval the client specifies in its CONNECT frame:
<client specified read heart-beat interval> * <grace periodmultiplier> == <broker enforced read heart-beat timeout interval>
For backward compatibility, if the grace period multiplier is not configured the default enforcement mode remains strict, e.g., transport.hbGracePeriodMultiplier=1.0. Attempts to configure the grace period multiplier to a value less than, or equal to 1.0 will be silently ignored.
STOMP clients that wish to be tolerant of late arriving heart-beats from the broker must implement their own solution for doing so.
Working with Destinations with Stomp
Note that the prefix in stomp /queue/ or /topic/ is removed from the string before passing it to ActiveMQ as a JMS destination. Also note that the default separator in MOM systems is . (DOT). So FOO.BAR is the normal syntax of a MOM queue - the Stomp equivalent would be /queue/FOO.BAR
Persistence of Stomp messages
By default, Stomp produced messages are set to non-persistent. You have to explicitly tell your Stomp library to add "persistent:true" to all SEND requests, for any messages that you want to persist across ActiveMQ restarts. This is the opposite of the default for JMS submitted messages.
Working with JMS Text/Bytes Messages and Stomp
Stomp is a very simple protocol - that's part of the beauty of it! As such, it does not have knowledge of JMS messages such as TextMessages or BytesMessages. The protocol does however support a content-length header. To provide more robust interaction between Stomp and JMS clients, ActiveMQ keys off of the inclusion of this header to determine what message type to create when sending from Stomp to JMS. The logic is simple:
This same logic can be followed when going from JMS to Stomp, as well. A Stomp client could be written to key off of the inclusion of the content-length header to determine what type of message structure to provide to the user.
Here's a quick example of how to use built-in transformer (taken from test cases)
In order to create your own transformer, you have to do the following:
For example the built-in transformer contains the following value
In case you want to debug Stomp communication between broker and clients you should configure the Stomp connector with the
This will instruct the broker to trace all packets it sends and receives.
Furthermore, you have to enable tracing for the appropriate log. You can achieve that by adding the following to your
Finally, you will probably want to keep these messages in the separate file instead of polluting the standard broker's log. You can achieve that with the following log4j configuration:
After this, all your Stomp packets will be logged to the
Since version 5.2, there is a simple Java Stomp API distributed with ActiveMQ. Note that this API is provided purely for testing purposes and you should always consider using standard JMS API from Java instead of this one. The following code snippet provides a simple example of using this API:
This example is distributed with the ActiveMQ distribution. You can run it from the
Stomp extensions for JMS message semantics
Note that Stomp is designed to be as simple as possible - so any scripting language / platform can message any other with minimal effort.
Stomp allows pluggable headers on each request such as sending & receiving messages. ActiveMQ has several extensions to the Stomp protocol, so that JMS semantics can be supported by Stomp clients. An OpenWire JMS producer can send messages to a Stomp consumer, and a Stomp producer can send messages to an OpenWire JMS consumer. And Stomp to Stomp configurations, can use the richer JMS message control.
Stomp supports the following standard JMS properties on SENT messages:
ActiveMQ extensions to Stomp
You can add custom headers to Stomp commands to configure the ActiveMQ protocol. Here are some examples: