On Wed, 8 Aug 2001, Serge Knystautas wrote:
> I started writing something, but now that I think about this, locking and
> spool really aren't related. A standard mail repository needs locking... if
> you have multiple threads potentially modifying messages in a repository,
> you need locking, regardless of whether it's being used as a spool.
If you have started to write something, could it be about overhauling how
the mailets and the spool work?
> I like the pluggable locking mechanisms idea (if someone else has the
> time/interest to write such stuff), so what about having some conf setting
> for any mail or spool repository to use an alternate locking mechanism
> rather than the simple in-memory one?
Yes, the lock server might work; as I understand it, James starts working
by a "trigger" generated by the spool. To be exact, by a new message that
arrives in the spool; the message that was received by the SMTP handler
and stored in the spool. When a message arrives, the spool's store()
method will notify all the waiting processor threads to start working and
process the message that is just stored in the spool. Those processor
threads, once were started by the spool manager(s) and wait for any
message to arrive in the spool (they wait due to the wait() method in the
spool's accept()). So, as long as you have a spool repository for each
instance of James, then you'd have no problem.
When the processor threads get notified by the spool to start, they will
get notified. I mean, the processors and the spool are in the same JVM, so
notifyAll() will work as usual no matter how unlock() gets done. In the
mail repository, you may have lockServer.unlock(message) instead of just
unlock(message), so you wouldn't have the callback problem.
BTW, I think I'm done with my spool repository implementation. I'm going
to send it to you (and Charles). It's for you to take a look. The
temporary message names cache is there. So you can see wether it would be
good to implement the feature in the main branch. It's heavily logged; I
log everything including each entry/exit to/from the methods.
By examining the logs (../logs/mailstore.log), having a message cache
would be good for the outgoing spool; yes, I separate the incoming and the
outgoing spools (even though they end up in the same db table). I have to
have both, so that each of the lock cache will store the incoming and
outgoing message names separately. The message cache could have been
working better if James had decoupled the spool manager and the processor
threads.
I think, in the next release of James, the message processing would be
better if it's not triggered by the incoming messages, but by time. You
can have threads that start running periodically. By having them, you can
separate how the spool manager and the processor threads work. It could be
beneficial, so that you can have a spool that can receive messages at any
time and put them in the outgoing spool according to the destinations. if
you have more than one spool manager, then it would be all right, the
process of wether storing the messages in the local repository or outgoing
spool could be done as fast as the messages arrive. The processor threads,
waking up timely, would see wether any messages exist in the outgoing
spool. If there's any, then try to send them. To have this, I think
there's only some change needed in the RemoteDelivery mailet (or in the
LinearProcessor).
I believe it would be good to have the (incoming) spool and the remote
delivery threads to work separately (not bind by the notifyAll()), so that
you can set the number of the spool manager threads and the remote
delivery thread differently. Currently, if you have, say 10 spool managers
running, and you have 10 mail destinations that couldn't be reached (then
James waits to retry sending them), basically, there's no process going in
the spool (eg: moving messages from incoming to outgoing), and no more
mail get sent out. Well, I may be wrong, but that's what I can see by
looking into the logs.
Oki
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
