Aloha John, I like the cron approach. Create on engine/dashboard for all the mail checking and processing and another one for the main processing. Currently I have a ruby process that queues to beanstalkd get mail requests and another ruby process that takes the off to get the mail. Any mail is put back on the beanstalk with a process to run that varies. I could make a ruote process read the beanstalkd queue some how, and execute the get mail process returning the information back to the beanstalkd. There are several things that may happen based upon the mail profile initially passed that really should be handled on the get mail side.
Is the beanstalkd code updated to work with the latest and greatest ruote? Mahalo Don French On Oct 3, 2012, at 1:57 PM, John Mettraux <[email protected]> wrote: > > On Wed, Oct 03, 2012 at 10:17:53AM -0700, Don French wrote: >> >> I have a need for a long running process to constantly (every few minutes) >> read several mailboxes. Is it better to just have a process that gets the >> mail and thens spawns another process that actually to all the processing >> of the mail. Or have a ruby process/scheduler that sits and spawns a new >> process to get the mail from one mailbox and then process it? >> >> The additional processing is be based upon the type of mail and the process >> defined for the particular mail box. >> >> When I say several mailboxes, right now it is < 100 however, hopefully it >> will be 1000's. Could have one process per mailbox or per group of mail >> boxes. > > Hello Don, > > it depends on lots of things. If you have a ruote process handling that, you > can cancel/pause it like you do for other ruote processes. If the process is > a dedicated Ruby process, you have to implement the cancel/pause by yourself. > If the process is Cron triggered, then Cron management tools are in order. > > After that it depends on the unhappy path, what to do when things go wrong, > when one has to reprocess a particular mailbox, etc. > > I guess you want to re-use the ruote facilities you built for your regular > processes, makes sense. > > But if you want to keep your main ruote engine clean of "low level > administrative processes", running that in a secondary ruote or from a > dedicated Ruby process / cron might be better. If there are 1000 "checking > inbox" processes cropping up, they might hide more important processes (if > you have a single ruote engine... that could require enhanced filtering in > the admin tools...) > > And just a small plug for the cron expression: > http://ruote.rubyforge.org/exp/cron.html you certainly know about it, but a > bit of spotlight is not bad. > > > Sorry for not providing an answer, best regards, > > -- > John Mettraux - http://lambda.io/jmettraux > > -- > you received this message because you are subscribed to the "ruote users" > group. > to post : send email to [email protected] > to unsubscribe : send email to [email protected] > more options : http://groups.google.com/group/openwferu-users?hl=en -- you received this message because you are subscribed to the "ruote users" group. to post : send email to [email protected] to unsubscribe : send email to [email protected] more options : http://groups.google.com/group/openwferu-users?hl=en
