Hi,
There is a thread pool for the spoolmanager, every thread simply take a
mail from the spool and let it run through a single processor (a
sequence of mailets). At the end of the processor the mail (if it still
exists) is stored to another processor or ghosted (or duplicated).
Another thread will take care of it. This thread instead will start
another mail (if present).
Thanks for your insights. If I understand correctly, a single thread
handles a single mail through a single processor. That would be exactly
what I need.
What happens if an error occurs and the mail is sent to the error
processor? If I understand correctly the error processor may be handled
by a different thread. In that case it's not OK to rollback the current
ThreadLocal transaction there: It might be a different one because James
may have picked another thread from the pool. Am I right here?
When the mail is read from the spool aa new Java instance is created, so
it is instead probably true that a single java instance of a Mail object
will be processed by a single thread, but James will use multiple java
instances for a single mail processing.
What exactly do you mean with multiple Java instances? Multiple
Instances of MailImpl or multiple instances of Thread or both?
The spool processing is not a short running operation and IMHO it is not
suggested to have transactions running from the beginning to the end.
My current processing takes <300ms, which isn't too bad for the life
span of a DB transaction IMO. I don't like the idea of starting and
commiting 10+ transactions for the processing of a single mail for both
performance and safety.
Keep in mind that unfortunately our spoolmanager is not (yet)
transactional: there are no atomic processing. This could lead to
duplicated processing: this is not a BIG issue because SMTP
specifications already ensure that we receive at least 1 copy of each
sent message but it does not ensure we'll receive only 1 copy.
It would be really nice if it could be made transactional (IMHO) at
least inside a single processor. It could be a major selling point vs.
other mailers. I understand that this can only work with a DB backend
and would be a major effort. Have you ever looked into Hibernate, it
supports virtually all major DBMS's.
thanks,
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
