On Apr 7, 2006, at 10:37 AM, Pjotr Prins wrote:

I have a few questions regarding the ZOPE mailer implementation:

I didn't write it. I have some pretty good guesses, though. Hopefully the author can confirm.

1. Why did you go for a file system implementation - as ZODB objects
are being made into a mail queue anyway? The Maildir step could have
been skipped, I suppose, just the connection to a mail server directly
over the network interface would suffice. Is there a specific reason
for the Maildir implementation?

Typically you have this kind of design because Zope only has a limited number if threads (usu. 4) that you don't want to tie up waiting for network traffic. So the intent is to not block.

2. The current implementation can only handle between 30-60 E-mail's a
minute. This is mostly due to the naming convention used for maildir
files (one a second - actually the Maildir naming allows in between
numbers, but you don't use that).

Ow. I wish you would fix that, or at least put in a collector issue with some good hints.

30 E-mails a minute is not really
scalable and has the (apparent) downside it (effectively) blocks the
Zope webserver for the duration (it should not, but it does, possibly
a locked ZODB?).

Possibly because it's waiting for an available filename given its naming conventions.

We have that experience sending out bulk E-mail reminders using that
module. Sending out 200 mails made the main ZOPE server inaccessible
for 3-4 minutes.

The reason I am asking is not so much an interest in fixing it for

I wish you would.

, as we can live with that performance issue, but I am looking to
implement a similar functionality for storing xParrot/ZOPE objects in
version control in a seperate thread. So I would like to understand
the reason behind the Maildir choice.

"Don't block."

Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to