[Catalyst] Sending 3000 emails.

[Len Jaffe]

On Fri, Dec 4, 2015 at 11:35 AM, Andrew <catalystgroup at unitedgames.co.uk>
wrote:

>
>
> one does not send any email directly as the result of a browser
> interaction,
> but rather one notes that an email needs to be sent (queues a job request),
> and a demon or cron job (a queue processor) creates ands sends the mail.
>
> ----> So let's do this. How do we go about it?
> Scenario - users want to be alerted via email when a new job on a job
> board is posted.
> So we've a website that's a Catalyst app.
>
>

> At some point in the app, - when a new job post is being created - we note
> that emails need to be sent to everyone who wanted a head's up on this
> event.
> So what am I doing?
>
>

> Am I using Email::Stuffer to send via sendmail, which on my system appears
> to be handled by exim (which can be installed in place of sendmail)...? Or
> are you saying using Email::Stuffer doesn't queue a job request - it just
> sends instantly - in which case - how do you queue?
>
> If you're handing off the mail to exim, you're fine.  Your implementation
is correct for your use case

The initial admonishment about queue is all about not making a web client
wait for your app to send an email as a result of some action by the
browser For example,  if the sign up for your service, queue a "send them a
welcome email" job, and let the web request request return. Then a separate
process sees that an email needs to be sent, generates the email and hands
it off to exim.  It's a different use case that the one you describe, and
mostly it allows you to server more web requests by making the requests
lighter.

So given that you're batch processing the email, we're back to resource
exhaustion as the primary likely cause of error. So you can do less work
per cycle (500 vs 3000), and/or debug the heck out of the process.
If you can get away with multiple 500s instead of 3000 all at once, then
definitely go for it.

But you still might want to put a few scopes on the process to see if it's
leaking memory ro doiong something else egregiously.



> Do I just write the source code for the email, and the mysql statement to
> get the user's emails, to a text file somewhere, in some directory, and let
> a Perl script running at set times via cron, read in the files, and process
> them later?
> Or should I be looking for certain CPAN mail queuing modules...?
>
>
Nah, you're good.



>
> _______________________________________________
> 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/
>
>


-- 
Len Jaffe - Information Technology Smoke Jumper - lenjaffe at jaffesystems.com
614-404-4214    @LenJaffe <https://www.twitter.com/lenJaffe>
www.lenjaffe.com
Host of Code Jam Columbus <http://www.meetup.com/techlifecolumbus/>  -
@CodeJamCMH <https://www.twitter.com/CodeJamCMH>
Curator of Advent Planet <http://www.lenjaffe.com/AdventPlanet/> - An
Aggregation of Online Advent Calendars.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scsys.co.uk/pipermail/catalyst/attachments/20151204/80e0cf1d/attachment.htm>