Rails 4.0 Sneak Peek: Asynchronous ActionMailer | Hacker News Reader

Rails 4.0 Sneak Peek: Asynchronous ActionMailer

reefpoints.dockyard.com

40 pointsbcardarella9 comments

I think this was the lowest-hanging fruit in Rails. Glad they've finally addressed it in core. Years of people using job queues just to send mail is finally over!

But, why doesn't this let me pass objects to Mailer methods? I can't help but think passing ids and finding the object again on the other side is bad design.

Myself, over the past few years, instead of a job queue, I have been using a simple gem called spawn (https://github.com/tra/spawn) to fork processes to asynchronously send mail from Rails. It lets me pass objects around... I hope that this asynchronous ActionMailer gets this functionality as well!

I think the main reason for this is that strange things can happen when you're passing marshalled objects around. For instance, say that your application has just created an Email object which has a "title" attribute, and it has been marshalled and put it into a queue. Your queue is a bit full, so it takes a while for the email to be processed. Right after it has been enqueued, you roll out an update to your code, changing the "title" field to be called "subject". As soon as your Email object is pulled from the queue, you will get NoMethodErrors from your asynchronous mailer code because the unmarshalled object doesn't have a "subject" method yet.

The reason queueing systems like Resque and Sidekiq pass id's around (instead of objects) is to make sure that the asynchronous worker always has a fresh object straigh from the data store. I guess that's why Rails core has decided to implement it like this as well.

With the default Rails.queue you can pass objects to your mailer. The issue is when you start using a background processor that requires the marshalling of the object. It is recommended to not use complex objects but if you are confident that the objects you are passing will marshall properly you should be OK

> I can't help but think passing ids and finding the object again on the other side is bad design.

It is good design. Why? Because you don't want to pass mutable state (read: your user model) across thread/process boundaries if you can help it. What if the mailer modifies it? What if the caller modifies it while the mailer is working with it? It may no longer be valid. Rather than trying to reason about all possible states it could be in, it's easier just to make the job bootstrap itself with all the data it needs.

Confining instances to threads is far more sane than using mutexes and locks or relying on your runtime's GIL to watch out for you.

Since you're unlikely to be sharing memory with your background processor, what you'd really be doing is marshaling the object on enqueue and unmarshaling on decode. In that case, you're no more susceptible to further modifications to the data than you would be with a DB lookup.

There of course may be other issues with marshaling. E.g., marshaling of procs is particularly tricky. But I've been marshaling with sidekiq for the past couple months and really haven't run into any problems. And it cleaned up the code a fair bit because I basically treat it as an RPC without any of the ceremonious DB lookups at the start of every async method.

Reply on news.ycombinator.com