Marius just told me he chose a file system solution because the
utility is not aware of ZODB, may not want to have ZODB and would
survive crashes. Good points, really.
On Fri, Apr 07, 2006 at 10:53:00AM -0400, Gary Poster wrote:
> 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.
If the queue was stored in ZODB it could still be handled on a
seperate thread. So I don't think it really is a blocking issue.
> >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.
Yes. And that is probably where the blocking occurs. The fix with
in-between numbers should be straightforward.
> >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.
If no one else does it and I feel confident enough... Maybe in a few
It would nice if a utility, on a seperate thread, could find the ZODB.
Maybe that can happen through ZCML configuration? I would need
something like that. In our case I can assume the ZODB is there since
we use the ZOPE3 webserver.
Zope3-dev mailing list