I have tried mime4j just now and I compared it with James that uses Javax
mail.

For the same 30+ MB message:

Timing:
mime4j: around  1 minute 20 seconds
javax.mail: 10 seconds

Memory:
mime4j -> without extra memory (default java -without any argument)
javax.mail -> -Xms512M -Xmx768M (without this extra, it fails)

For the 200+ MB file:

Timing:
mime4j: 7 minute and 10 seconds
javax.mail: fails even with extra memory -Xms512M -Xmx768M

Memory:
mime4j: the same as with 30MB

Other observations:

Mime4j uses nice processes
javax.mail uses user processes

Mime4j when running, my mouse is still responsive
javax.mail, my mouse is not really responsive

So it seems a bit dangerous to use javax.mail since we will never know when
some emails will go to error folder because of OutOfMemory.


----------------

Other problem I encountered using mime4j (sample tester: MessageTree), it
raises exception when processing text/plain with charset ISO-8859-1.

I saw that someone has incorporated mime4j into James, though still
experimental. But I don't find any version of James that contains mime4j.

Thanks.

Regards,
Edward
On 12/31/05, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
>
> > getFlags is not really important. But it also crashes when I try to get
> the
> > filename of the attachment, i.e. message.getFilename (of the Part). I am
> not
> > sure if there is other way to get the filename of the attachments. The
> email
> > header certainly does not contain the filename of the attachment.
>
>
> I think there is no easy solution to your problem.
>
> The only idea I have is the following:
>
> - Check wether the MimeMessage you get is a MimeMessageWrapper (it
> should if it's read from the repository), if it's a MimeMessageWrapper
> then change the MimeMessageWrapper code to give you visibility of the
> source "MimeMessageSource source = null;" (now it has package visibility)
>
> - Parse the message source with a different mime library (mime4j:
> http://mime4j.sourceforge.net/, look for the  MimeStreamParser class).
> Mime4J should be more memory friendly than javamail.
>
> I'm not sure this will work or even fix the memory problem, but this is
> the first attempt I would do.
>
> Let us know of your progress!
>
> Stefano
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Reply via email to