OK- I’ve been using ActiveMQ and ActiveMessaging for weeks now on EVE Metrics. And it’s great! Kinda. The performance is fantastic, I’ve got no complaints there. ActiveMQ is an absolutely solid, fantastic message broker. It’s easy to manage, rivalled only by RabbitMQ in general quality, and great to work with. ActiveMessaging, however, has a way to go.
The lack of fault management and good process management is a problem. Quite often workers would not be used for an hour or two, and MySQL would drop the connection. You’d expect AM to bottle out or reconnect at that point, but instead it just silently carries on, grabbing messages into a black hole. Not ideal. Getting the processes working well was difficult too- I ended up with a few shellscripts to manage them, running on a cronjob to restart them every hour to avoid the MySQL timeout problem. Not exactly ideal.
So, I’m moving the processing on EVE Metrics and Nexus (Which previously used AM/ActiveMQ for alert sending, amongst other things like API crawling) to a pure-Ruby solution from the guys who did Shopify, delayed_job. As well as being pure-Ruby (and thus not needing any external servers like ActiveMQ, simplifying install/setup) it’s got real provisions for locking, persistence even after working, and fault management. And it’s all ActiveRecord based, making an admin interface a cinch to add on. This should help loads, as debugging the AM setup was a bit hit and miss, and there are still bugs in there- see the lack of updates on the Orca/PLEX pages!
So, hopefully by the end of the weekend I’ll have Nexus ported, EVE Metrics ported, and some more stable queues….
Off to RubyManor in London on Saturday, if Boris doesn’t close Bakerloo as well as District/Circle. Looking forward to George’s talk on Nanite, which I was looking at as an alternative to AM/ActiveMQ before I stumbled upon delayed_job- Nanite looks very cool, though for different jobs, and it’s worth looking at if you haven’t already.
Hello –
The mysql connection issue was introduced in rails 2.1, and a patch is forthcoming – in the meantime better workarounds were posted to the list quite awhile ago. It’s my fault, been busy launching a new site, so I fell behind on this lately.
The error handling in active messaging depends on how you implement your message processing. It supports all kinds of retry logic, for example, which takes advantage of using a broker for async processing, which other solutions will not offer easily. This is not the default, as idempotent processing is not assumed, but not hard to set up either.
Sorry I didn’t hear about your issues sooner; these sound like solved problems that need better documentation. Thanks for airing your grievances, if only in retrospect – at least it will help me improve things for the next guy, if not for you.
-Andrew