After replacing the file-based spool with an in-memory spool implementation and eliminating a per-message WARN and an INFO log-message and dropping the hidden PostMasterAlias-mailet, the performance went to ~16,600 messages/min. At this point james and the client split the CPU evenly, indicating that james probably would have gone up to ~30,000 messages/min on a 3GHz P4, Win2k, JDK1.5.0_01, NTFS with a message size of 10.9kB.
Sounds good. At ~10kb/message, that's ~300 mb/min or 5mb/s? Sounds pretty nice.
I'll attach my changes if there's any interest.
I would like some of your improvements, though notes below.
Initially, there were stability issues, since zero
file i/o lead to lock-ups (of james _and_ Windows,
thread priorities?), which I countered by introducing
a forced wake-up from wait() calls every 100
milliseconds and forcing a Thread.yield() after each
notify() call for good measure (the yield() probably
would have been sufficient, I just dread the missed
notifies syndrome).
BTW, I don't really like wait()/notify(), I much prefer Doug Lea's synchronization primitives, LinkedQueue would probably work here.
Since Doug Lea's advanced thread-handling library is available as a separate download pre-JDK 1.5, we /should/ be able to bundle it with James and support our current JVMs.
My point being, I'm all behind switching our current approach to one that uses a solid thread-switching library.
The in-memory spool repository does not interfere with the other mail repositories, since the AvalonMailRepository class was not changed; all the change is in AvalonSpoolRepository. One caveat: spool recovery is of course meaningless after a crash.
Actually, make a copy of AvalonMailRepository and AvalonSpoolRepository, calling them MemoryMailRepository and MemorySpoolRepository (or whatever). At the end of your config file, you can see how to define memory: as a mail and spool repository that points to that new class. Then for various configurations you could switch from file://foobar to memory://foobar.
This would allow us to bundle your in-memory version and let people switch as they want.
-- Serge Knystautas Lokitech >> software . strategy . design >> http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
