Oops - my bad.  From what I saw, I was under the impression that it didn't
do this.  (No apparent incoming store being my main clue.)

Sorry for not getting all my facts straight ahead of time...

> -----Original Message-----
> From: Serge Knystautas [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, April 20, 2002 2:22 PM
> To: James Developers List
> Subject: Re: Suggestion
>
>
> I'm happy to report James already does this (and actually has
> been doing
> it since day 1).  When messages are received via SMTP, James does not
> send a 250 Message received until it is written to disk.
> Then as it is
> processed, the message is not removed from the spool until it is
> successfully processed.  Pretty much no matter when you kill
> James, it
> shuld never lose a message and in certain cases duplicate a
> message if a
> processing was interrupted half way through.
> --
> Serge Knystautas
> Loki Technologies - Unstoppable Websites
> http://www.lokitech.com/
>
>
> Jeff Keyser wrote:
> > I would like to make a suggestion that I feel would make
> James a little more
> > robust.  (I would offer to make the change myself, but I'm
> not familiar
> > enough with the code to do this.)
> >
> > Here is the potential situation:  James receives an e-mail,
> and responds to
> > the sender that it has been received.  James then begins to
> process this new
> > e-mail, but something happens before it's done - either the computer
> > crashes, James crashes, or whatever.  This e-mail is lost,
> because the only
> > copy of it was in memory.
> >
> > What I would suggest is that James write the e-mail to a
> store while it is
> > receiving it, before it sends the final response to the
> sender.  James could
> > then use this store as its incoming e-mail queue, and
> remove e-mail from it
> > after they have been processed.  If the computer crashes
> before the e-mail
> > is written to the store, the sender never gets a final response, and
> > (theoretically) holds the e-mail to try again later.  If it crashes
> > afterwards but before processing is done, James rereads the
> e-mail from the
> > incoming queue when it restarts, and starts the processing again.
> >
> > Anyway, it's just a suggestion.
>
>
> --
> 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]>

Reply via email to