You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Jeff Keyser <JK...@telocity.com> on 2002/04/20 19:07:38 UTC
Suggestion
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Suggestion
Posted by Serge Knystautas <se...@lokitech.com>.
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:sergek@lokitech.com]
>>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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Suggestion
Posted by Jeff Keyser <JK...@telocity.com>.
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:sergek@lokitech.com]
> 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:
> <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>
Re: Suggestion
Posted by Serge Knystautas <se...@lokitech.com>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>