> -----Original Message----- > From: Danny Angus [mailto:[EMAIL PROTECTED] > Sent: 21 October 2003 09:47 > To: James Developers List > Subject: Re: MailetException vs MessagingException > > > > > > > OTOH I suspect we should consider implementing listeners to > handle transient and asynchronous failure of transport and > store, and keep exceptions for irrecoverable internal failures. > > If we're bound to JavaMail (which we are) specialising > messaging exception to MailetException makes little sense if > MailetException doesn't offer any "added value", in other > words is nothing more than a functionally equivalent alias > > This all makes me wonder how javaMail's event stuff can be > implemented and used by James' provders (assuming that we > write some which actually despatch some events, as the RI > providers don't!), whether we can make use of this by having > the container listen for asynchronous failures. If we can do > this would it benefit us to adopt this pattern in services > which James provides access to? For instance.. for a > transient error of DNS failure should we actually use the > listener model to tell the container to respool the message, > wait and retry. rather than throw an exception? The trouble is, I think this should be done on a case-by-case basis :( I do like the idea though. It would make catching common errors very easy, by just binding a default handler to most containers. > > I mean, we are trying to do two things here, first we want to > ensure that no message breaks James, so we throw exceptions > and catch them in the container, but secondly we want to be > able to indicate operational conditions which are failures, > but are not exceptional, they are expected and manageable. > Perhaps we should be doing something else to support > management of a whole class of predictable transient failures > of the system to achieve its goal, rather than technical > failure to process a message. Interesting point this. Qmail differentiates between transient and permanent failures. If a part of the Qmail pipeline fails it will send back a code indicating a failure mode: For example: An over quota error is a permanent error and should be dealt with as such, However a failure in a processing step *may* be transient (DB failure for example) The issue in dealing with transient failures is when to retry (and how much) In my way of thinking a MailetException ("there was a problem")would be (mostly) classed as transient, whereas a MessagingException ("this message cannot be processed/delivered due a problem in it") would be permanent Just my 2p worth... > > > > ************************************************************** > ************* > The information in this e-mail is confidential and for use by > the addressee(s) only. If you are not the intended recipient > (or responsible for delivery of the message to the intended > recipient) please notify us immediately on 0141 306 2050 and > delete the message from your computer. You may not copy or > forward it or use or disclose its contents to any other > person. As Internet communications are capable of data > corruption Student Loans Company Limited does not accept any > responsibility for changes made to this message after it was > sent. For this reason it may be inappropriate to rely on > advice or opinions contained in an e-mail without obtaining > written confirmation of it. Neither Student Loans Company > Limited or the sender accepts any liability or responsibility > for viruses as it is your responsibility to scan attachments > (if any). Opinions and views expressed in this e-mail are > those of the sender and may not reflect the opinions and > views of The Student Loans Company Limited. > > This footnote also confirms that this email message has been > swept for the presence of computer viruses. > > ************************************************************** > ************ > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
