views:

96

answers:

3

We are getting close to releasing our new rails app and so far interest seems very strong we are a little worried about where bottle necks will be. One seems to be system e-mails on signup and in other situations. Is this correct?

Should individual e-mails to users be sent asynchronously in the background? If so, what would be the best solution?

I have looked at a few solutions and can't seem to find anything definitive.

A: 

Same thread, if you ask me.... by generating a file in a drop folder, which an email server picks up. Then there is not too much overhead, so a seaprate threads makes little sense.

At least this is how I always handle this.

TomTom
"generating a file in a drop folder which an e-mail server picks up" - I've never heard of this before. Can you elaborate a bit more on how this works? Can you do this with ActionMailer?
ChrisH
Well, i dont do ruby ;) ASP.NET only. I have a local mail server listening to a specific folder, and ASP.NET writes a file into that actually pickup folder - the mail daemon listenes to changes there, picks up the file, sends it (actually to my mail relay server). Problem is: email sending ca ntake some time and I dont want to ahve anything non-persistent.
TomTom
A: 

In the backgroud using http://github.com/tobi/delayed_job

clyfe
A: 

I would say it depends on your requirements. If you need to be able to inform the user that sending mail failed, do it in the same thread.

If not, sending mail should support things like retries etc, so I would put the message into a queue/the filesystem/database table/etc and have another thread/process deal with the details of sending.

Angelo Genovese