Yeah, the one problem we're talking about is *while* James is saving over the previous copy of the message, the danger being that while it is being written you kill the server and you end up with a partial message.
No problem. All thoughts appreciated. -- Serge Knystautas Loki Technologies - Unstoppable Websites http://www.lokitech.com/ Jeff Keyser wrote: > 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]>
