Test mail - please ignore this

["Boyalla, Raveendra" <Ra...@dfa.state.ny.us>]

-----Original Message-----
From: Aaron Knauf [mailto:aknauf@xtra.co.nz]
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:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
> 
> 


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>