[Catalyst] Sending email safely with Catalyst

[Zbigniew Lukasiak]

On Sat, Apr 12, 2008 at 1:06 AM, Dave Rolsky <autarch at urth.org> wrote:
> On Fri, 11 Apr 2008, Jonathan Rockway wrote:
>
>
> > In an ideal world, you should be able to dump the messages into your
> > mail system's queue as quickly as you can dump them into a database
> > table (adding to the mail queue is a disk write, adding to a database is
> > a disk write, unless you've turned off data integrity).
> >
> > I could see how calculating the text of 10000 mail messages during a
> > request would be slow, but why would you want to do that?  Usually
> > you'll just want to say "Your account was created, [% name %]!" and
> > queue that.  The template rendering and the mail system's queue should
> > be more than fast enough to handle that during a request.
> >
> > As for bulk emails, you probably have a process that calculates those
> > outside of your Catalyst app anyway (running from cron), so calculate
> > them, dump them into the mail queue, and let your mailer daemon figure
> > out what to do.  Much better than putting a queue in front of a queue,
> > IMHO.  This is UNIX after all.
> >
>
>  The big problem I've run into when sending lots of emails from a web app
> (just hundreds, in this case), is that it can be slow enough the browser
> times out.
>
>  Presumably you could have a similar problem with a work queue as well.
>
>  Ultimately, I suspect a solution that forks _immediately_ and then does its
> thing (whatever that thing may be) is going to be necessary past a certain
> scale.
>
>  Then the trick becomes monitoring that forked process.
>
>  Another solution might be to come up with a way to queue up the job with a
> single write and do the full email generation via cron. Either way, you have
> to add complexity to your app if you want to provide feedback on the job
> status to the user.
>
>  I'll be working on this soon for an app I'm creating, and I suspect I'll go
> the route of doing a single insert and processing via a cron job. The upside
> of this is that for a multi-user app, I won't end up forking a whole bunch
> of email sending processes and I can exercise some control over the rate
> that email is generated.
>

My first approach was to do the sending in a cron job - but then came
the requirement that the emails should be sent as soon as possible.
Now I have a forking model, but I don't know if I implemented it
correctly (the mod_perl guide recommends against forking
http://modperlbook.org/html/10-2-Forking-and-Executing-Subprocessesfrom-mod_perl.html).
I am also contemplating a compromise of sending the first few emails
immediately and the rest from a cron job.


>
>  -dave
>
>  /*==========================
>  VegGuide.Org
>  Your guide to all that's veg
>  ==========================*/
>
>
>
>  _______________________________________________
>  List: Catalyst at lists.scsys.co.uk
>  Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
>  Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
>  Dev site: http://dev.catalyst.perl.org/
>



-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/