Re: [Zope3-dev] bit puzzled with directDelivery+smtpMailer
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 - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] bit puzzled with directDelivery+smtpMailer
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. That makes directDelivery unsuitable for production use. > 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. Marius Gedminas -- I would suggest re-naming "rmbdd()". I _assume_ that "dd" stands for "data dependent", but quite frankly, "rmbdd" looks like the standard IBM "we lost every vowel ever invented" kind of assembly lanaguage to me. -- Linus Torvalds signature.asc Description: Digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] bit puzzled with directDelivery+smtpMailer
Hello, 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. 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. Obviously they would be fired in the middle of tpc_finish. Any ideas, pointers? -- Best regards, Groszer Adam -- Quote of the day: The reports of my death are greatly exaggerated. - Mark Twain ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
