james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Serge Knystautas <ser...@lokitech.com>
Subject Re: writing mails to the spool store in between processors
Date Tue, 07 May 2002 00:13:12 GMT
A message can leave the spool if the state is GHOST... (to answer your 
question) OR if there are no more recipients associated with that message.

I forget whether you said you had read over the code, but the 
suggerstion you're making to keep messages in memory across processors 
would take a lot of code refactoring.  The threads, processor 
configuration, and mailet and matcher loading are all really geared to 
treat processors as independently operating entities.
Serge Knystautas
Loki Technologies - Unstoppable Websites

Shilpa Dalmia wrote:
> I'm trying to avoid reading & writing from the persistent store in the spool
> everytime messages are passed from 1 processor to another. Currently since
> the message is renamed after each processor, it is rewritten to the spool
> which is a performance hit. This renaming needs to be done as the message
> gets removed from the spool when it leaves the processor. Now, if we do not
> rename the message & remove the message only if it has finished processing
> (check the state is GHOST), we avoid rewriting to the spool. So my question
> was that is this assumption right that the message always ends with GHOST
> state? Would there be any other repurcussions in not renaming the message?
> In addition to this, we can also introduce a memory cache, so that the mail
> is written to persistent store only once (useful for retries etc) & all
> subsequent read & writes (of the message & the message header) are done in
> memory.
> Shilpa Dalmia
> -----Original Message-----
> From: Serge Knystautas [mailto:sergek@lokitech.com]
> Sent: Monday, May 06, 2002 4:33 PM
> To: James Developers List
> Subject: Re: writing mails to the spool store in between processors
> I think we're talking in circles.  What problem are you trying to solve? 
>   We can go from there.

To unsubscribe, e-mail:   <mailto:james-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:james-dev-help@jakarta.apache.org>

View raw message