on 10/8/2000 11:23 PM, Kapil Thangavelu at [EMAIL PROTECTED] wrote::
> There has been intermittent talk of improving mailhost's ability to
> scale. i just wanted to solicit some comments to some ideas for
> improving mail host performance.
> Stage I. Persistent Socket
> 1. make the smtp connection persistent
> 2. preface sending mail with a 'noop' operation to verify connection
> 3. overide __setstate__ to open connection
> i'm not sure if this will yield any real world benefit but i like the
> style better than opening a new connection for every new message.
> Stage II. Transaction Aware
> 1. Store sent mail in a volatile
> 2. on transaction commit begin (tpc_begin), send all mail, if error
> abort transaction
> 3. reset volatile
> again i'm not sure of real world performance, but the design seems
> better and the added benefit that it will play nicely with the
> transaction machinery and not send unesc. emails.
> Stage III. Intelligent Q. aka the BulkMailHost
> 1. implement mailer thread / sole function to send mails from queue and
> intelligently manage a outgoing queue and deferred queue.
> 2. implement extensions to sendmail tag for immediate sending of mail
> which will wake/signal mailer thread after depositing into outgoing q.
> extension options are
> 3. mailer thread on a timer, so it will wake on either a sendmail tag
> with immeadiate extension or on timer expiration and send mail from
> queue, messages with error due to connection or placed in deferred
> queue. messages with undelivarable errors are either deleted or placed
> in a deleted queue.
> 4. all queues are viewable and manageable from the management interface.
> obviously this makes the sendmail tag async to the message being sent.
> i'm not sure if this something that really should be implemented in a
> ZODB default file storage due to the high write nature of the system or
> just dumped to the fs. again this seems questionable also because a
> proper mta should be operating on a store and send principle
For some time, I've been wanting to see Mail handled more like SQL Methods,
with the Mailhost object being some sort of 'SMTP Adapter' and perhaps
having MailMethods\Templates(?) - Objects that basically make it easier to
handle constructing a mail message template, maybe separate out the headers
and the body and make adding attachments easier.
You can write a transaction manager object without it being a storage. The
ZopeLDAP Adaptor works this way. It's not flawless transaction handling,
but it does delay actually writing out LDAP Modification commands until the
transaction is committed. During the transaction, the Entry objects
accessed and modified are kept in memory so when they're asked for later in
the same transaction, you are reading the modified Entry.
> hmmm... looking through the source of the 2.2.2 mailhost i see a
> scheduledSend method, anyone know what this is from/for?
This was from the old Scheduler which I don't think is even around anymore.
The old Scheduler was sortof a placeholder for sometime in the future when
we'd be able to do scheduled events. I'm not sure of any plans to revive or
Jeffrey P Shell, [EMAIL PROTECTED]
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -