james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Serge Knystautas <ser...@lokitech.com>
Subject Re: Disabling the spool in James 2.2.0?
Date Sat, 15 Jan 2005 03:36:36 GMT
Gabor Kincses wrote:
> 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. sergek@lokitech.com

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message