[Zope-dev] Zope (or Python?) not completely thread-safe...?!

[Jeff K. Hoffman]

On Fri, 11 Feb 2000, Hannu Krosing wrote:

> "Jeff K. Hoffman" wrote:
>  
> > We are in the process of transitioning our main web asset to Zope. This
> > site sends broadcast e-mails to all of its members (10,000+) when an
> > important news item is posted to the site, which can potentially happen
> > more than once a day.
> 
> I guess that more productive use of time would be letting the maillist 
> expansion to sendmail or similar program and work on getting the interface 
> to it right (and maybe writing some HowTo-s on how to set it up to always
> store-and-forward)

I assume you mean using a Cc: or Bcc: to let the MTA distribute a single
message body multiple times? Sure, for our purposes here, that is probably
what we will do.

> Of course this will not work very well if you want to give a personalized 
> message to each list member. Still it may be wise to just prepare the 
> messages and let a well-tested MTA handle the actual distribution.

We do not need a specialized message per user. The users are divided into
affiliation groups, though, so we will have one e-mail go to 200 people,
the next to 150 people, the next to 413 people, etc. But, this should pose
no problem.

> An interesting task would be to use /usr/sbin/sendmail executable in
> os.system (or pipe, i.e. popen, popen2 or popen3) call to do the
> processing instead of talking to smtp socket.

This works fine, and is the way our current (proprietary) system operates.
My personal opinion, however, is that talking to an SMTP socket makes the
system easier to configure, easier to install (doesn't require ANY mailer
to be installed on the web server), and all around better. Of course, I
could be wrong.

> > I am obviously (due to the volume we send out) interested in providing
> > Zope with more robust, high performance SMTP mail capabilities. The items
> > you mention above would be a great start to addressing our needs.
> 
> Still you could end up rewriting whole sendmail, which is at least a moderate 
> size project, even if done in python ;)

Oh, no! I will not attempt anything close to rewriting sendmail. The
changes Jim mentioned would mean:

  1) A call to <dtml-sendmail> stores the message as part of the current
     transaction, and
  2) When the transaction is committed, any e-mails which are included in
     the transaction are queued for asynchronous delivery to the MailHost
     when possible.

This would allow, for instance, us to send out 500 e-mails (one of our
affiliation groups) and abort all 500 of them if the enclosing transaction
is rolled back (say, a database error during e-mail construction.)

This would also mean that 500 e-mails could be queued for delivery VERY
quickly without blocking while they are sent to the SMTP host. This is
very attractive to us.

We will also require some other features, such as:

  o Submitting an e-mail to be broadcast creates a Job.
  o Users with appropriate permissions can view a list of jobs, pause a
    job, resume a job, kill a job, etc.
  o Users with appropriate permissions can view job status, such as the
    rate that e-mails are being relayed to the MailHost, the lifetime of
    the job thus far, estimated time remaining, etc.

I don't think achieving the above goals requires anything close to the
effort of sendmail. Someone correct me if I'm wrong. ;-)

> Hannu

--Jeff

---
Jeff K. Hoffman                                         704.849.0731 x108
Chief Technology Officer                                mailto:jeff@goingv.com
Going Virtual, L.L.C.                                   http://www.goingv.com/