Re: Archive One Message Behind Using -add
On February 7, 2002 at 15:33, Don wrote: You could easily do some tests to find out what is going on by replacing webnewmail with a simple program (like cat) that just dumps the contents /var/mail/beta to some temp file. Then you can examine the temp file to see if the new message actually exists or not. I had actually tested that possibility with a ksh and in fact it did execute the ksh script before the email landed in the spool file. What was confusing is that it would work without the -add. Could be a race condition. If the call to webnewmail is a forked sub-process, then the addition to the beta spool file could be happening in parallel. If this is the case, the -add causes mhonarc to run much faster over the spool file since it will skip already archived messages. Without the add, it is reconverting every message, making the processing of the spool file slower and potentially giving time to sendmail to perform the append operation before mhonarc gets to the end of the file. --ewh
Re: Archive One Message Behind Using -add
--- Earl Hood [EMAIL PROTECTED] wrote: On February 5, 2002 at 10:19, Don wrote: I'm attemting to keep an archive automatically up to date using a .forward file. When I use the -add option, the archive is always one e-mail behind. ie, If the mail box has 4 messages, only 3 will display on MHonArc. When message #5 comes in, MHonArc will display 4 messages. If I remove the -add option, which has the effect of rebuilding the entire archive, the archive is kept up to date. This works for now, but as archives get very large this would of course be problematic. Any Ideas? My initial hunch tells me it may have to do with the mechanics on how sendmail is invoking things. Does sendmail invoke each forward component in sequence (and if so, what is the order), or in parallel? If there is some parallelization, there could be race conditions between when sendmail appends beta's spool file to when mhonarc (via webnewmail) reads the spool file. If sequence, it is possible that sendmail calls |./webnewmail first before appending to beta's spool file. You could easily do some tests to find out what is going on by replacing webnewmail with a simple program (like cat) that just dumps the contents /var/mail/beta to some temp file. Then you can examine the temp file to see if the new message actually exists or not. I had actually tested that possibility with a ksh and in fact it did execute the ksh script before the email landed in the spool file. What was confusing is that it would work without the -add. .forward file: \beta, |./webnewmail Snippet of ./webnewmail: @ARGV = (-quiet, -rcfile, $MRC/date_p_beta.mrc, -rcfile, $MRC/indice.mrc, -title, Project Beta Date Index (by reverse date), -ttitle, Project Beta Thread Index (by reverse date), -sort, -reverse, -treverse, /var/mail/beta, -outdir, /export/home/beta, /var/mail/beta); With what you have, using webnemail in the .forward is useless. I.e. The .forward file tells sendmail to pipe a copy of the message to webnewmail, but the @ARGV settings is telling mhonarc to read from the spool area. I.e. Standard input of webnemail (which contains a copy of the new message) is being ignored. Hence, you are relying on sendmail to append the new message to /var/mail/beta before webnewmail is called. arrgh. You're right. I'd gotten sloppy switching between a manual add and an 'automatic' add script. Thanks. That fixed it. With what you have, it is probably better to use a cron job, which I generally advocate. With cron, you can managing load better and deal with problems better. I hear 'ya. However when trying to give a demo an instant update sells better than and in just a minute you'll see the message converted. Thanks for your help. It's fixed. Very impressive software BTW - Thanks! Don __ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.yahoo.com
Re: Archive One Message Behind Using -add
On February 5, 2002 at 10:19, Don wrote: I'm attemting to keep an archive automatically up to date using a .forward file. When I use the -add option, the archive is always one e-mail behind. ie, If the mail box has 4 messages, only 3 will display on MHonArc. When message #5 comes in, MHonArc will display 4 messages. If I remove the -add option, which has the effect of rebuilding the entire archive, the archive is kept up to date. This works for now, but as archives get very large this would of course be problematic. Any Ideas? My initial hunch tells me it may have to do with the mechanics on how sendmail is invoking things. Does sendmail invoke each forward component in sequence (and if so, what is the order), or in parallel? If there is some parallelization, there could be race conditions between when sendmail appends beta's spool file to when mhonarc (via webnewmail) reads the spool file. If sequence, it is possible that sendmail calls |./webnewmail first before appending to beta's spool file. You could easily do some tests to find out what is going on by replacing webnewmail with a simple program (like cat) that just dumps the contents /var/mail/beta to some temp file. Then you can examine the temp file to see if the new message actually exists or not. .forward file: \beta, |./webnewmail Snippet of ./webnewmail: @ARGV = (-quiet, -rcfile, $MRC/date_p_beta.mrc, -rcfile, $MRC/indice.mrc, -title, Project Beta Date Index (by reverse date), -ttitle, Project Beta Thread Index (by reverse date), -sort, -reverse, -treverse, /var/mail/beta, -outdir, /export/home/beta, /var/mail/beta); With what you have, using webnemail in the .forward is useless. I.e. The .forward file tells sendmail to pipe a copy of the message to webnewmail, but the @ARGV settings is telling mhonarc to read from the spool area. I.e. Standard input of webnemail (which contains a copy of the new message) is being ignored. Hence, you are relying on sendmail to append the new message to /var/mail/beta before webnewmail is called. With what you have, it is probably better to use a cron job, which I generally advocate. With cron, you can managing load better and deal with problems better. --ewh
