[Zope3-dev] bit puzzled with directDelivery+smtpMailer

[Christian Theune]

Hi,

Am Donnerstag, den 29.03.2007, 21:37 +0300 schrieb Marius Gedminas:
> Hi,
> 
> On Thu, Mar 29, 2007 at 01:31:12PM +0200, Adam Groszer wrote:
> > I'm trying to catch somehow the exception that's coming when the SMTP
> > server IP address is misconfigured or the SMTP server is not
> > responding.
> > 
> > My problem is that the sending works using the transaction manager.
> > That means the exception comes after
> >   File "U:\zope\svn_zope33\src\zope\publisher\publish.py", line 138, in publish
> >     publication.afterCall(request, obj)
> >   File "U:\zope\svn_zope33\src\zope\app\publication\browser.py", line 78, in afterCall
> >     super(BrowserPublication, self).afterCall(request, ob)
> >   File "U:\zope\svn_zope33\src\zope\app\publication\zopepublication.py", line 167, in afterCall
> >     txn.commit()
> > That means I don't have a big chance to catch it in my app.
> 
> That's a feature.  You don't want to send emails about changes made in
> transactions that were later aborted.  In particular, when you encounter
> ZODB ConflictErrors a couple of times, you don't want three copies of
> the same email to be sent.
> 
> Unfortunately, that means the actual sending must be done in the second
> phase of the two-phase commit, and it is not supposed to ever fail at
> that point.  

At least partially untrue. It doesn't have to be done in the second
phase.

You can do it in the first phase and make your data manager have a very
low sort key (e.g. a magic key that is lower than anything else) so it
will always get vote() as last.

Unfortunately controlling this isn't easy and doesn't seem to be
intended to be controlled past the fact that the sort keys should be
stable.

> That makes directDelivery unsuitable for production use.

True in this incarnation.

> > Using queuedDelivery might be a solution, but I still don't have too
> > many chances to give feedback of the error.
> > 
> > There is a IMailErrorEvent, and IMailSentEvent but they don't seem to
> > be used.
> 
> Ouch.  I do not remember why the events were never fully implemented.
> 
> > Obviously they would be fired in the middle of tpc_finish.
> 
> Sending events is the same as running arbitrary code.  That's a bad
> thing to do during transaction commit.  There was some discussion (years
> ago) that the transaction mechanism should acquire a way to register
> some callback for code that should be run in a new transaction, after
> the current one is committed.  I do not remember how that discussion
> ended.
> 
> > Any ideas, pointers?
> 
> zope.sendmail could use some loving care and attention.  For example,
> the queued delivery thread will loop forever trying to deliver a message
> with an ill-formed recipient address once every three seconds.
> 
> In the meantime, this seems to work adequately: use queuedDelivery, and
> send a test message after depoying the application.  If it doesn't come
> through, check the error logs.
> 
> Note also that if the nearest SMTP server accepts an email, that does
> not guarantee delivery.  We've hooked up incoming mail to a bounce
> message processor in one of our Zope 3 apps that matches message IDs in
> bounce messages with IDs of sent emails and can take appropriate action.

MailDropHost could be useful to talk to. It's a good tool in
Zope-2-Land.

-- 
gocept gmbh & co. kg - forsterstraße 29 - 06112 halle/saale - germany
www.gocept.com - ct at gocept.com - phone +49 345 122 9889 7 -
fax +49 345 122 9889 1 - zope and plone consulting and development
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : http://mail.zope.org/pipermail/zope3-dev/attachments/20070329/b26193f8/attachment.bin