Heap Protection and other confusion (trying to contribute)

[mikezzz]

Hi,

I am interested in contributing to the jboss mail project. I have spent today looking at implementing heap protection (basic as per the wiki). However I have run into a couple things that require me to ask a couple of questions.

1) Where should the text body of a mail message sit within the org.jboss.mail.message.Mail object. At the moment the constructor gobbles up the entire message and stores all of it in the header ArrayList. The body will be consistently an array of 0 length. Is this by design or is it a bug.

2) As a result of the above (I think) large messages are not handled very well. The body gets read in using the stunning LineInputStream (as a header). Tests I've run show that a 3MB message will blow a 40MB heap. Makes a setting a threshold for the heap protection interesting.

Could someone (Andrew) please confirm 1. is a bug. If so I will attempt to fix and continue testing to see if 2. disappears and finalise an implementation for basic heap protection.

Cheers,
Mike.

[acoliver]

No if you look for "makeBody" you'll see where it fills the body. It is not entirely shocking that a 3MB message would blow a 40MB heap with the default JBoss install as JBoss takes nearly a 32MB heap if you do no other configuration.

"
body = new byte[calculateBodySize(bodyList)];
body = makeBody(bodyList,body);
"

Advanced heap protection will require a seperate mbean (names in below pseudocode are demonstrative but stupid):

BodyStore store = BodyStoreService.newBodyStore();

storeid = store.getId();
BodyOutputStream stream = store.getOutputStream();

stream.takeInput(inputStream);
this.bodyStrore = bodyStore;

Then getBodyAsInputStream should be added to Mail:

if (bodyStore == null) {
return new ByteArrayInputStream(body);
} else {
return BodyStore.getInputStream();
}

BodyStore should have two implementations: File-based and Database. The file based simply create a new file for every body with some kind of integer naming scheme.

The database one will be more complicated. I'm going to say something shocking....it probably is easiest to just not use a persistence engine (no hibernate/cmp) and implement our own database transparency layer. I'll explain, CLOB/BLOB is still not very well standardized. The MYSQL driver even fakes it so far as actual locators are concerned. Oracle can support locators, but you have to use oracle specific types. I suggest that we support Oracle, MySQL and the JDBC3 version. This will make installation more complicated as we'll have to have a way to create the table with the BLOB/CLOB.

-Andy