Brief statement of JBMS design goals
acoliver May 26, 2006 12:09 PMJBoss Mail Server is a central compoent in the JBoss Collaboration Server suite. The mail server has some general principles for which its design adheres:
1. open protocol support
2. reutlization of appserver features (such as JAAS login modules)
3. extensibility
4. databasestore independence
5. scale
In particular I'd like to address the latter. JBMS in its early stages loaded every mail into memory at least once (actually more than once). Now we are very careful not to do that!
Loading mails into memory keeps pressure off of the database but limits scale in terms of acheivable rate of mixed size mails (read some will be 40k some will be 8mb). Moreover, due to the way that Java manages memory, in a -server configuration, it is not possible to see when you've "bitten off more than you can chew" in terms of memory consumption. Thus we choose maximum scale and stability over low-end performance. Meaning it is likely that a higher number of really small messages could be processed "in memory" provided you are willing to risk loosing messages in the event of a failure or risk running out of heap space (thus loosing said messages when the VM dies). Also as memory becomes full Java reduces performance by executing more freqent major and full GC runs.
Thus the principal performance gains are to be found through faster storage medium (RAID 1+0, write behind cache with backup). Reliability is storage dependent and counterweights performance (database replication, backup, etc). A poorly performing database will significantly degrade performance.
That being said, it is possible to deoptimize this structure on purpose or by accident. The Store interface is designed to be pluggable. There is no reason that you cannot plug in a more memory-oriented version. You can also (at any point) get access to the raw stream of a mail or stored mail. If you pass this to JavaMail then JavaMail will completely load the mail into memory. For some systems, doing this in the maillisteners will provide acceptable perforamance and stability (provided that volume is relatively low and the allowed number of incomming connections is low).
We will be offering plugins which deoptimize this structure as options for the first release (JASEN for instance pretty much requires this) and will seek to replace them by either working with the authors or moving to alternatives. The default structure will always adhere to this goal and base level functionality will never require anything that does not adhere to this goal. I realize this is not an incontrovertable design decision, but a lot of work, benchmarking, crashing and mistakes were made along the way to arrive at it. Please discuss this rationally and offer proof rather than conjecture.
Thanks,
-Andy