Am reading some interesting stuff now.
There's an odq argument you can pass to sendmail, which adds stuff to the mail
queue without waiting to send,
and there's a tutorial on Perl Maven for sending to multiple addresses using
Email::Stuffer without wasting memory creating multiple objects...or so I
gather from an initial skim read...
----- Original Message -----
From: Andrew
To: The elegant MVC web framework
Sent: Friday, December 04, 2015 9:03 PM
Subject: Re: [Catalyst] Sending 3000 emails.
Exim itself should be the queue and processor shouldn't it?
----- Original Message -----
From: Len Jaffe
To: The elegant MVC web framework
Sent: Friday, December 04, 2015 8:48 PM
Subject: Re: [Catalyst] Sending 3000 emails.
On Fri, Dec 4, 2015 at 2:04 PM, Andrew <[email protected]>
wrote:
If you're handing off the mail to exim, you're fine. Your
implementation is correct for your use case
---> Of course, I'm guessing I'm handing off to exim - I should
probably do something to check!
Look for Email::Sender configuration. It probably defaults to sendmail,
which is what you want.
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.
----> So what does the separate process have to be? A process apart
from my Catalyst app - like an entirely different perl script that could be a
cron job or something - or can I return a response to the browser within my
catalyst subroutine, and then call a private catalyst subroutine to handle the
email sending?
What triggers the sending of the 3000?
I use a table as a queue, and I write a program that loops over the queue
until no more work to do:
1.. read the least-recently-processed job from the queue that has work
to do
1.. determine work-to-do as unassigned. (PID is null)
2.. mark it as assigned
1.. i keep a pid column and update the pid into the record
3.. do the work
1.. the whole job of some slice
4.. if done,
1.. perform post job bookkeeping
5.. else
1.. update in-progress status (num_complete)
2.. update PID = NULL
1.. so the job processor can come back too it.
I use this algorithm to send 500 emails at a time (in RoR). After 500, the
job goes to the end of the queue, and the next job is processed.
My processor is a stand-alone script that is run from cron.
---> And yes, after the quick fix, it wouldn't hurt to debug and see if
there are memory issues.
That's the fun part.
_______________________________________________
List: [email protected]
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive:
http://www.mail-archive.com/[email protected]/
Dev site: http://dev.catalyst.perl.org/
--
Len Jaffe - Information Technology Smoke Jumper - [email protected]
614-404-4214 @LenJaffe www.lenjaffe.com
Host of Code Jam Columbus - @CodeJamCMH
Curator of Advent Planet - An Aggregation of Online Advent Calendars.
----------------------------------------------------------------------------
_______________________________________________
List: [email protected]
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[email protected]/
Dev site: http://dev.catalyst.perl.org/
------------------------------------------------------------------------------
_______________________________________________
List: [email protected]
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[email protected]/
Dev site: http://dev.catalyst.perl.org/
_______________________________________________
List: [email protected]
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[email protected]/
Dev site: http://dev.catalyst.perl.org/
