Plans next week/performance stuff...

[acoliver]

Just in case it seems like I drop off the face of the earth next week. I'll be working on profiling/performance testing (http://jira.jboss.com/jira/browse/JBMAIL-62, http://jira.jboss.com/jira/browse/JBMAIL-63). Probably the first part will just be getting my network of test boxes back up and running (I used some for spare parts, primarily network components).

I'm hoping the SpecJ stuff has tests that are useful. However, I may develop a small test kit of our own just because the SpecJ can't be used without license (JBI has a license) and we can't publish unless we're ready to publish official numbers. Frankly I doubt we'd wow anyone with numbers on my crappy 500mhz iMac or 2 year old $500 emachine that I bought at costco...and those are the two fastest boxes! However, right now I want to get an idea and a baseline to judge what configs perform well, least well and judge when each release gets slower/faster. I also want to get a continuous integration build running again. I may have that spit out numbers from my own test kit if you will.

Follow next week, I am going to Japan for a week. So its unlikely that I'll be very responsive. I've never been to Japan so I have no idea how unresponsive I will be.

Following that I plan to knock out (if no one has beaten me to it):

1. http://jira.jboss.com/jira/browse/JBMAIL-103
2. http://jira.jboss.com/jira/browse/JBMAIL-80
3. http://jira.jboss.com/jira/browse/JBMAIL-53
4. http://jira.jboss.com/jira/browse/JBMAIL-102
5. http://jira.jboss.com/jira/browse/JBMAIL-73
6. And stuff on IMAP (we have a donation in this area that I'll be committing early on in parallel with the performance stuff. I'm hoping it is not a white elephant because it has no unit tests...)

I'm hoping to leave most of the storage/mailbox stuff for this release to Mike, but may get involved in screwing it up for IMAP. There is probably one more hidden feature in here which is "refactor security for IMAP/mailbox changes" but I plan to have the IMAP spec on the plane with me to Japan for a little light reading before I start making ignorant statements here -- right next to Dan Brown's Deception point.

-Andy

[clebert.suconic]

Did you mean Specj or SpecMail2001?
http://www.spec.org/mail2001/results/mail2001.html


Specj doesn't use any JavaMail API in its tests.


Clebert

[acoliver]

yeah.

Yeah SpecMail...that thing. The thing you sent me.

Good glad it doesn't use JavaMail...we hate JavaMail...it smells like old cheese...we hate cheese to....especially me because I'm lactose intollerant...okay actually I'm not sure its lactose...I can have butter...but no cheese...cheese is evil.

[mikezzz]

Good glad it doesn't use JavaMail...we hate JavaMail

And neither to we now. Yippee!!! I committed the ristretto stuff I did yesterday. I need to sort out the JDK14/JDK5 compatibility thing, but it's not really an issue for us as we don't use the Sasl module which has the problem. Until the ristretto guys merge my patch for the rcpt error code we will maintain a patched version that works for us.

Mike.

[acoliver]

God mike, I'm nominating you for sainthood. Lookie here:

JAVA_OPTS="-server -Xms128m -Xmx128m"

My sever has not balked under my usually high load of mail despite running in the default JBAS4 heap settings! M2pre1 (or so with some Andy's special sauce patches) was stable at around 512 for me on Jboss 3.2.7 and MySQL. M3 seems to be stable at 128! Now I've not got my hopes up the first time I get a 10mb attachment -- but pretty damn impressive when the subsequent releases require LESS memory.

-Andy

[mikezzz]

It wasn't just the mail store that improved this, it was also the mailbox. There were a few aspects of the old entity mailbox that were a bit over zealous with the use of memory. The best bit is that there is still more that can be done to make it faster and lighter. E.g. I would like to use Hibernate projections to support the LIST command. Currently LIST loads all of the message headers into memory, where as we only need the size of the message and its Id.

[acoliver]

Ahh yes. Presently also we miscalculate it by some order of magnitude which causes Tbird to think there isn't enough space to download it :-)