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:[EMAIL PROTECTED]] 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. -- Serge Knystautas Loki Technologies - Unstoppable Websites http://www.lokitech.com/ Shilpa Dalmia wrote: > Spool processing would have had a problem if we didn't rename the message > before storing as it would get removed from the spool the moment it returned > from the processor & the message would be lost. I am not quite familiar with > the temporary error processing, but in case of an error if it stores the > message again with the same name, wouldn't it be ok as long as the message > is not being deleted? > > Shilpa Dalmia > > -----Original Message----- > From: Serge Knystautas [mailto:[EMAIL PROTECTED]] > Sent: Monday, May 06, 2002 2:51 PM > To: James Developers List > Subject: Re: writing mails to the spool store in between processors > > > 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. -- 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]>
