> One possible change, hinted at in comments I left in the code, would be for > the spool manager to become single threaded, dishing off messages to worker > threads. This would be quite similar to a common usage pattern with NIO, > should eliminate contention and synchronization issues, and improve > performance.
That'd be a good idea. It might be more efficient to only hand out the message_id's and locks rather than the messages themselves, after all we have an open issue with message I/O, and have the concurrent processes do the I/O. Have the manager manage the list, but delegate the whole handling of the objects, not just the processing. Of course you'd still need to deal with the distributed lock scenario where two James instances are looking at one repository, but if you had a distributable spool manager focused soley on that one task it might make a big difference. d --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
