I agree, even if it were possible, and I don't think it can be, mailets cannot be atomic actions. All we can ever do is try to make failure behaviour predictable.
> -----Original Message----- > From: Aaron Knauf [mailto:[EMAIL PROTECTED]] > Sent: 08 December 2002 05:50 > To: James Users List > Subject: Re: fault tolerance of smtp server and mailets > > > Noel, > > I understand the issues here. The point that I was trying to make was > that it is actually not possible to absolutely guarantee "once and only > once". There will always be a window, however small, for either a loss > or a duplicate (in the case of JAMES, a duplicate). > > JAMES currently takes all reasonable measures toward "once and only > once". Hunting for an absolute guarantee (even if it were possible) > would not really make JAMES any more useful to 99.9% of users. > > Cheers > > ADK > > > > Noel J. Bergman wrote: > > Aaron, > > > > There are distributed transaction managers. Moot point in this context. > > > > Let's consider a simple example. Let's say that James accepts > a message and > > the sender's connection is pulled at just the wrong point. James has > > spooled the message, but the sender can't get the notification. > > > > RFC 1123 states that 'When the receiver-SMTP accepts a piece of mail (by > > sending a "250 OK" message in response to DATA), it is accepting > > responsibility for delivering or relaying the message. It must take this > > responsibility seriously, i.e., it MUST NOT lose the message > for frivolous > > reasons, e.g., because the host later crashes or because of a > predictable > > resource shortage.' Therefore, James may see that the > sender's connection > > has gone bye-bye, but that doesn't mean James should not send > the message. > > > > Meanwhile, the sender doesn't know if the message was > sucessfully sent. RFC > > 1123 (amongst others) states that the sender "MUST be able to > [retry] until > > a delivery attempt succeeds." > > > > Sending e-mail is not a database transaction. James tries to > be as reliable > > as possible. James should not send the "250" until after the > message is in > > the spool. To do otherwise would be a defect requiring a fix. Once the > > message is in the spool, it stays there until after a sucessful transfer > > elsewhere. > > > > If you need guaranteed delivery over SMTP, you could have the > destination > > send an ACK after it has successfully processed the message. The sender > > continues to periodically resend the message until receiving > the ACK. The > > receiver must discard duplicates. > > > > > >>It may be possible to track the progress of a mail through the processor > > > > > > As you noted, this would require making a database update for each > > transition between mailets. There is a different solution, > available today. > > Configure a separate processor element for each non-idempotent > operation. > > That way there will be a spooler transition recording the > change where it is > > necessary. > > > > --- Noel > > > > > > -- > > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
