I think the team at Twitter have done a fantastic job of late. The app I’m working on has some resemblances to Twitter & it’s status updates, so that’s another reason to use Starling.

I’m looking forward to any more Rails & background process related posts.

My experience has been that message flow has never been the issue. It’s always message processing that is the problem. My bias will always be towards a solution like Starling because it’s simpler. Unless I have a need for absolutely guaranteed message delivery or have huge message backups, I don’t see a reason to introduce Java, ActiveMQ, and ActiveMessaging to the mix. I reference huge message backups because Starling is basically a persisted memory queue. If your queue gets too backed up, you will run out of memory. JMS has many modes that allow for queue to grow far larger than available memory if necessary.

One more thing, Rails is still not able to handle distributed transactions easily, so the absolute guarantee with ActiveMQ is not happening anyway. You will need to write additional code to handle failures rather than relying on transactional rollback like you can in Java and other platforms.

Based on your experiences with the two (albeit, presumably on different apps without a fair, scientific, architectural comparison), have you noticed any performance difference between Starling and ActiveMQ/ActiveMessaging?

I’m happy with starling for my purposes. Between its stability, persistence, and the create method (as well as some protective code), I have a system that has a very good chance of not loosing anything.

For other systems I built, the combination of ActiveMQ and ActiveMessaging are a rock. It is not uncommon for those to run for years without any problems. ActiveMQ is a real queue that supports all forms of transactional integrity. Using it will require adding new a new client, runner, and poller to workling. It would be an interesting addition to workling.

Although, if you’re happy with Starling, I’m sure I will for the time being. It’s very snappy, at least in comparison to BgRb - and it’s up and running in production without any apparent overhead on the production slice (using New Relic Bronze).

The RSS parsing worker is now on a daemon (see the Railscast on Custom Daemons) - it was going to be called via crontab (and before that it was on a backgroundrb schedule) but this would’ve loaded the Rails environment every time. Sleeping a daemon avoids that.

Your :create method looks like the post-downtime tidy-up method I was considering, with which any loose items would be picked up and distributed. Feed_items (polymorphic references) have ‘feeds’ as the has_many_through model (i.e. the reference required for notifying user_id of feed_item_id) and their is validates_uniqueness_of with scope through user_id and feed_item_id - this means we can try distributing the same feed_item twice and only the ‘feeds’ which weren’t sent will be distributed on a second attempt. But, wouldn’t it be possible to wrap a transaction block around the worker? Quick research suggests transaction blocks were ripped out of AR and moved to a plugin - still, is that not something we could use with Starling?

Thanks for the insights

For the Inquisix jobs that have to run, I use a backing database table to keep state of each job. With that I can add a create method on my worker to restart anything that didn’t complete.

For example:

# Initialize by restarting any jobs that didn’t complete
def create
jobs = ImportJob.find_in_state(:all, :processing) # acts_as_state_machine
jobs.each { |job| ContactWorker.asynch_import_contacts(:job_id => job.id) }
end

It’s not as safe as JMS, but between the persistence of starling and calling create when started up again, it’s pretty close.

Does this help?

I’ve been in the middle of an Engine Yard deployment for a few weeks now - most of the delays have been due to factoring in BackgroundRb (EY use Monit, and they do a whole load of ground work for you regarding deployment recipes etc, BgRb has been causing several issues). So, BackgroundRb is probably just about to be dropped for the two background processes we run; ‘feed item’ distribution (ala Twitter and Facebook home pages) and RSS parsing, which itself creates one type of ‘feed item’ for the distribution worker. The feed item distribution is the only candidate for Starling, the RSS worker is just going to drop back to crontab hitting a module.

Just yesterday I swapped over BackgroundRb for Starling/Workling (thanks Railscasts) for the feed item distribution and all seems to be working well in development. I also did tons of reading round on Starling. However, the app can’t really afford to lose anything from the queue if something was to go wrong, and this is something I didn’t really understand even after lots of reading round. How can Starling be handled with regards to downtime or when the worker code is changed and the process needs restarting? Does the ‘feed item’ table need to know when feed items have been sent (was thinking along the lines of a ‘is_distributed’ boolean that would be updated true at the end of the worker transaction, and if things go wrong, I kick up a process to send anything that hasn’t been sent) or can we rely on the Starling log to cover this?

How are you handling potential Starling downtime at Inquisix? Is it still doing the biz?

p.s. I tried playing with BackgroundJob in place of Starling runner - oddly, it didn’t seem to work, although BJ has been working when I use it outside of Workling. Either way, I’m now a big fan of Workling/Starling.