Tuesday, May 8, 2012

What's new for Stomp in ActiveMQ 5.6

Version 5.6 of ActiveMQ has been a long time coming but its finally here and brings with it some great new features.  In this post I'm going to cover what's new for those of you using STOMP clients to communicate with ActiveMQ.

STOMP v1.1 Support

Probably the biggest change in ActiveMQ 5.6 is that we now support STOMP v1.1 but that's not the only thing we've done, there's plenty of new goodies even if you are stuck using a STOMP v1.0 based client.  With the addition of STOMP 1.1 support STOMP you get:
  • protocol negotiation to allow for interoperability between clients and servers supporting successive versions of STOMP
  • heartbeats to allow for reliable detection of disconnecting clients and servers
  • NACK frames for negative acknowledgment of message receipt
  • Support for virtual hosting.
I won't spend a lot of time rehashing the STOMP 1.1 spec here as its laid out quite nicely in the protocol specification page here.

Other New STOMP Features and Fixes

Of course support for STOMP 1.1 isn't the only thing we added to our STOMP support, there's several other new goodies in there as well.  Lets take a look at what else you can now do with the STOMP Transport in ActiveMQ 5.6. 

Queue Browsing

A normal subscription on a queue will consume messages so that no other subscription will get a copy of the message. If you want to browse all the messages on a queue in a non-destructive fashion, you can create browsing subscription. To make a a browsing subscription, just add the browser:true header to the SUBSCRIBE frame. For example:

SUBSCRIBE
id:mysub
browser:true
destination:/queue/foo

^@
 
Once the broker sends a browsing subscription the last message in the queue, it will send the subscription a special “end of browse” message to indicate browsing has completed and that the subscription should not expect any more messages. The “end of browse” message will have a browser:end header set. Example:

MESSAGE
subscription:mysub
destination:
message-id:
browser:end

^@
 
The Queue browsing support works for both STOMP 1.0 and STOMP 1.1 clients so you don't need to upgrade your client in order to take advantage of this new feature.

Message Selectors and Numeric Values

Prior to the 5.6 release you couldn't specify a numeric selector expression on a STOMP subscription, this has now been fixed so you are free to subscribe to a destination via STOMP using selectors such as the following:

SUBSCRIBE
id:mysub
selector:someId = 42
destination:/queue/foo

^@
 
With this subscription any JMS Message's sent to this destination with an numeric message property named 'someId' and a value of 42 will be picked up as expected.

STOMP+NIO+SSL Transport

In 5.6 we've added NIO+SSL transports for both Openwire and STOMP clients which allow you to connect large numbers of SSL based STOMP clients to a single broker instance.  You can configure a STOMP+NIO+SSL TransportConnector in you broker as follows:


    transportconnector name="stomp+nio+ssl" uri="stomp+nio+ssl://0.0.0.0:61616"  
  

STOMP 1.0 default heartbeat configuration

Unlike STOMP 1.1 the original STOMP 1.0 does not provide for an inactivity monitor since there was no defined hear-beat capability.  A client connect that stays idle will remain active on the broker indefinitely.  With STOMP 1.1, the inactivity monitor has come into play in response to the heart-beat header.   Since not all your clients might not be upgraded to STOMP 1.1 right away we added the capability to specify a default heart-beat value to the transportConnector so that you can still timeout idle STOMP connections.  You can setup this default value on your connector as follows:

   stomp://0.0.0.0:0?transport.defaultHeartBeat=5000,0

In the absence of a heartbeat header, as in the STOMP 1.0 case, this default value would cause an InactivityMonitor with read check interval of 5 seconds to be installed on each new broker stomp transport connection.  Any client that remains inactive (sends no messages) for more than 5 seconds will have their broker connection closed.  You should tune this value based on the exceptions of the behavior of you clients.

Wrap Up

I've tried to just quickly touch on some of the enhancements that we've made for those of you using STOMP clients in ActiveMQ v5.6.  There's a ton of other new and improved features in 5.6 as well given that there were some 435 issues resolved for this release.  I encourage you to download this new release and take it for a spin.  If can ask questions on our mailing list if you run into trouble. 

2 comments:

Unknown said...

Queue browsing is a neat idea for STOMP. I was able to utilize it with ActiveMQ-5.7 - thank you.

One question, though, queue browsing appears to be specific to the broker one connects. I have 2 brokers with network connections in between. If there are messages on broker A and none on broker B, I can only "browse" and receive data from broker A. I can "browse" broker B for the same queue and get no data.

Steffen

Tim said...

This is expected. A queue browser takes a shapshot of the queue through a short lived consumer. The network bridge is by default a demand forwarder, such that messages are only forwarded when there are consumers on other
brokers.

With the browser, the consumer (and hence demand) is transient, so it may take a snapshot before the forwarding has a chance to kick in. And the forwarding stops when the consumer goes away once the browse snapshot completes.

One way to make this more deterministic would be to have a statically configured destination in the network connector configuration such that messages for that destination are forwarded irrespective of demand.