In RabbitMQ 2.6.0 we introduced Highly Available queues. These necessitated a new extension to AMQP, and a fair amount of documentation, but to date, little has been written on how they work.

There's a lot of hot stuff happening in the web technology lately. JavaScript seems to be bearing the torch, both browser-side and server-side. At the RabbitMQ HQ we're interested in developments in the wide world of messaging, and we're particularly excited about the JavaScript angle on messaging - namely WebSockets and related technologies.

I was asked to do a short presentation during the PubSubHuddle meetup. The talk was about current development of WebSockets, its issues and building web applications using them.

One of the problems we face at the RabbitMQ HQ is that whilst we may know lots about how the broker works, we don't tend to have a large pool of experience of designing applications that use RabbitMQ and which need to work reliably, unattended, for long periods of time. We spend a lot of time answering questions on the mailing list, and we do consultancy work here and there, but in some cases it's as a result of being contacted by users building applications that we're really made to think about long-term behaviour of RabbitMQ. Recently, we've been prompted to think long and hard about the basic performance of queues, and this has lead to some realisations about provisioning Rabbits.

All of a sudden there's just one week to go until the PubSub huddle. It's a one day conference, in London, about messaging. Not just RabbitMQ, but ZeroMQ, MQTT, XMPP and PuSH.

WebSocket technology is catching up, but it will take a while before all browsers support it. In the meantime there are loads of projects that aim to substitute for WebSockets and enable 'realtime' capabilities for web apps. But all attempts solve only a part of the general problem, and there isn't any single solution that works, is scalable and doesn't require special deployment tricks.

While the firehose is quite a cool feature, I always thought that it was a shame we didn't have a simple GUI to go on top and make it accessible to system administrators. So I wrote one. You can download it here.

We are very pleased to announce the availability in beta of RabbitMQ as a Heroku add-on. With our RabbitMQ service on CloudFoundry, this extends our commitment to supporting the community of cloud application developers.

We believe that cloud messaging is fundamental in two senses. First as a core capability to build applications that scale to cloud use cases as explained in our blog post launching RabbitMQ on CloudFoundry. And second, because messaging can be extended to solve common problems like integration and data push. For example: to connect traditional on-premise applications with virtualized and cloud deployments.

The idea of 'realtime web' or messaging using web browsers has been around for quite some time. First it was called 'long-polling', then 'Comet', the latest incarnation is named 'WebSockets'. Without doubt it's going in a good direction, WebSockets is a neat technology.

But during the fight for realtime capabilities we've lost focus on what is really important how to actually use messaging. In the web context everything is request-response driven and marrying a typical web stack to asynchronous messaging isn't easy.

Recently we launched a RabbitMQ service for Cloud Foundry, making it simple to spin up a message broker to use with your apps on Cloud Foundry. There are tutorials online for using it with Ruby on Rails and with Java apps using Spring. Here we are going to look at using the RabbitMQ service with Node.JS apps.