writing mails to the spool store in between processors

[Shilpa Dalmia <Sh...@PostX.com>]

Can we assume that every mail will always indicate end of processing with
the status "GHOST" which means the last mail processor will always set it to
GHOST status. If we can go by that assumption then we can avoid the problem
of renaming the mail message before putting it on the spool while being
passed from 1 processor to another, by putting a check in JamesSpoolManager
run() method to remove the message from the spool only if the mail status
is GHOST. 
   The advantage of this scheme is that for performance reasons, we can
write the mail message to persistent store (disk, db etc) just once & cache
the mail message in memory which can be stored & retrieved from memory in
between processors and when the mail is completely processed it can be
removed from persistent store. Ofcourse, caching can be made a configurable
option.

Shilpa Dalmia

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

Re: writing mails to the spool store in between processors

[Serge Knystautas <se...@lokitech.com>]

This wasn't actually the big problem (I think the spool manager already 
keeps the message in memory until complete).  The current issue we were 
facing (with respect to saving the same message) was during remote 
delivery when we had a temporary delivery failure... it would update the 
error message field on the Mail object, and then store the message again 
with the same name.
-- 
Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com/

Shilpa Dalmia wrote:
> Can we assume that every mail will always indicate end of processing with
> the status "GHOST" which means the last mail processor will always set it to
> GHOST status. If we can go by that assumption then we can avoid the problem
> of renaming the mail message before putting it on the spool while being
> passed from 1 processor to another, by putting a check in JamesSpoolManager
> run() method to remove the message from the spool only if the mail status
> is GHOST. 
>    The advantage of this scheme is that for performance reasons, we can
> write the mail message to persistent store (disk, db etc) just once & cache
> the mail message in memory which can be stored & retrieved from memory in
> between processors and when the mail is completely processed it can be
> removed from persistent store. Ofcourse, caching can be made a configurable
> option.
> 
> Shilpa Dalmia


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

Re: writing mails to the spool store in between processors

[Serge Knystautas <se...@lokitech.com>]

Ah, actually I just caught that you were talking about going from one 
processor to the next.  Anyway, the spool processing wasn't where the 
renaming the message problem was necessary, but I see what you mean.  I 
don't think it's really necessary since this wouldn't affect the 
problem, and I still think the repository should be reliable enough to 
resave a message.
-- 
Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com/

Shilpa Dalmia wrote:
> Can we assume that every mail will always indicate end of processing with
> the status "GHOST" which means the last mail processor will always set it to
> GHOST status. If we can go by that assumption then we can avoid the problem
> of renaming the mail message before putting it on the spool while being
> passed from 1 processor to another, by putting a check in JamesSpoolManager
> run() method to remove the message from the spool only if the mail status
> is GHOST. 
>    The advantage of this scheme is that for performance reasons, we can
> write the mail message to persistent store (disk, db etc) just once & cache
> the mail message in memory which can be stored & retrieved from memory in
> between processors and when the mail is completely processed it can be
> removed from persistent store. Ofcourse, caching can be made a configurable
> option.
> 
> Shilpa Dalmia


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