[Catalyst] Sending 3000 emails.

[Andrew]

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 <catalystgroup at unitedgames.co.uk> 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: 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  www.lenjaffe.com

    Host of Code Jam Columbus  - @CodeJamCMH
    Curator of Advent Planet - An Aggregation of Online Advent Calendars. 




----------------------------------------------------------------------------


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



------------------------------------------------------------------------------


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scsys.co.uk/pipermail/catalyst/attachments/20151204/25943299/attachment.htm>