-----Original Message----- From: Aaron Knauf [mailto:[EMAIL PROTECTED]] Sent: Sunday, December 08, 2002 12:50 AM 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]>
