Message queues – implementations and more crazy demands

Hurrah for throwing random ideas around – Simon Wistow has implemented my wouldn’t it be nice.. message queue idea. Regrettably, it’s written in Perl, which means it won’t get any ‘cool kid’ traction and be lost to the mists of history. But good effort anyway, eh?

Though Paul’s comment on that post raises a good point. This stuff belongs in the frameworks nowadays. Sure, there are add-ons. But frankly I want to consider it like the ORM – you can swap out another one if you want, but look, here’s a perfectly good message passing abstraction built right in!

Wait! More ideas! This one has been stewing for longer. It’s a pain writing message handlers in Rails. I want to send email. Or IMs. Or do something useful. But these things are almost always implemented as methods on models, and in the model I’m not supposed to know about the outside world. In rails, models don’t know how to generate urls, for instance (whereas in Django, models are responsible for knowing what their authoritative representation URL is. This is alternately great and weird to me. How do I have a different URL for the object on the mobile site?).

The interface I really want is the standard MVC model, where in this case, the View is the message transport layer, and my message handling code is in the Controller. I want access to my url helpers, so if I proxy incoming Jabber messages to queue messages (which is probably a good idea) I can reply to these messages and link to web pages. I want a session abstraction, tied to the transport layer, so I can fake a long-running conversation, and I want it to look like the web session abstraction. Sure, I can do the session stuff myself, but it belongs in the transport layer abstraction – noone would seriously suggest you write your own web session handler nowadays, would they? The ‘web’ interface to my app shouldn’t be ‘special’ like this.

Image by bartmaguire

Running a Jabber server under Debian with eJabberd

I like to run my own jabber server, so that I can be contacted as Also, I’m a sucker for punishment. I’ve run serveral different Jabber servers over the last year or so, and yesterday I started toying with ejabberd. It was probably the easiest to set up of any of the servers I’ve tried, and I recommend it.

I’m running Debian etch, and installing the daemon was a matter of:

sudo apt-get install ejabberd

Once installed, edit /etc/ejabberd/ejabberd.cfg. A ‘%’ at the beginning of a line is a comment, and lines finish with a ‘.’ character. This config file is read only once, and the settings are put into the ejabbed server database on startup. Unfortunately, that’s probably already happened, so uncomment the override_acls. directive – this makes the server re-read the ACL settings from this file on next startup.

I’ll assume that you own the ‘’ domain and want the JID ‘’. Uncomment the line below ‘%% Admin user’. It wants to be something like

%% Admin user
{acl, admin, {user, "user", ""}}.

Change the line below ‘%% Hostname’ to set the hostname of the server:

%% Hostname
{hosts, [""]}.

You may want to look through the rest of the settings. But don’t bother, they’re all very boring. Now restart the server, to pick up the new settings:

sudo ejabberdctl restart

ejabberdctl can also register your admin / jabber user if you’ve turned off anonymous registration:

sudo ejabberdctl register user <password>

Right, you’re done. Assuming that the DNS A record for resolves to the machine you’ve been playing with (it doesn’t have to, see below), you now have a Jabber server with an admin user. You can visit to administer your server, but there’s not a huge amount to do there.

DNS SRV records

If the A record for doesn’t resolve to your server you can still run a server for by pointing DNS SRV records to your server. In fact, you should do this anyway, in the same way that your email will arrive if the A record for your domain points to the mail server, but MX records are still a good idea.

Assuming your Jabber server runs on a machine called, you’ll want the following scary DNS records:

_xmpp-client._tcp 900 IN SRV 5 0 5222
_xmpp-server._tcp 900 IN SRV 5 0 5269
_jabber._tcp      900 IN SRV 5 0 5269

You can check that they’re been set properly using this excellent tool, but it’ll probably take a while for the DNS updates to propagate. If you have the dig command line tool, you can also try

dig -t srv

to ask your local DNS server for one of the SRV records.


You don’t have to use ejabberd. Viable alternatives are:

  • djabberd – lovely if you know Perl and want to extend/hack on a Jabber server. Unfortunately it’s somewhat tricky to configure out of the box, isn’t in Debian, and needs various things checked out from subversion repositories if you want to do esoteric things like preserve your friends roster across daemon restarts or have messages queued when you’re offline.
  • jabberd – I really don’t want to trust an internet server written in C any more. It was the original/first Jabber server, if this makes you approve of it more.
  • Not running your own Jabber server – Very worth considering. Unlike running your own mail server or web server, it’s very hard to change your mind later and have someone else host it. I know of very few 3rd party Jabber hosting providers. Yet. Running your own server is purely a vanity thing, but hosting your own email domain used to be a vanity thing too. However, one company that will host your Jabber server for you is..
  • Google apps for your domain – One of the apps Google provide is a chat (Jabber) server. You can ignore everything else they do and just use the Jabber server part, assuming you have enough DNS access to your domain to point the SRV records to it.