Java Heap Space errors with large emails

Aspose.Email Product Family
3

Thanks for your quick response, Margarita.

Unfortunately, however, this data originates from outside our company so we need the ability to load our client’s data that has emails with large attachments like this. It’s not like we have a choice in the matter on how the email is constructed.

Please provide other suggestions on how to handle this type of email using the Aspose libraries. Thank you.

4

Hello @jmuth,

Unfortunately, there is nothing we can do in this regard. Email formats are not intended for large data transport. Aspose.Email was designed with these restrictions taken into account.
Anyway, we can discuss with developers what options may be added to solve the issue.
Please share more details about your case (what classes are used, where do you load messages from, how do you handle emails, sample code, etc.).

Thank you.

5

Margarita,

Thanks for clarifying but not sure that’s going to help us handle emails of this type. I didn’t include a code snippet because I thought it was evident from the stack trace but our use case is about as simple as you might imagine:

String filePath = “path_to_large_email_file.msg”;
MsgLoadOptions mlo = new MsgLoadOptions();
mlo.setKeepOriginalEmailAddresses(false);
MailMessage mailMessage = MailMessage.load(filePath, mlo); <===== this is where the error occurs

Please let me know if you need anything else. Thank you.

6

@jmuth,

Please clarify how you further use the loaded message?
Are you changing any properties?
Are you saving it in any other format?
Are you just reading the properties?
Are you processing attachments?
Also, you use the MailMessage class. Have you tried using the MapiMessage class?

I apologize for asking so many questions. We need to know the details to try resolving the problem.

7

Hi, Margarita.

Here are answers to your follow-up questions:

  1. We are NOT changing properties
  2. We are NOT saving the email in another format
  3. We ARE reading the metadata properties of the email
  4. We would attempt to process the email’s attachments if we could get it to load but never make it far enough to do that
  5. We see similar issues when using either the MailMessage or the MapiMessage classes.

Please let me know if you need any more information. Thank you.

8

Hello @jmuth,

Thank you for the answers.
We’ll discuss this case with the developers and let you know a solution as soon as possible.

9

@jmuth ,

Could you please provide us with the message file you are having problem with?
Upload the file to some cloud service like GoogleDrive and share a public link to the file.
We’ll make this topic private so that no outsiders can see your link.

Thank you.

10

Hi @margarita.samodurova
This file was shared with one of your co-workers under a paid support ticket - 176968

Thanks.

11

Hello @aweech,

I got it, thanks for the info.

12

Hello @aweech,

We are working on optimization methods for a large attachments.
Also, аfter processing the message, you can release resources using the following methods:

msg.close()

or

msg.dispose()

or

try (MapiMessage msg = MapiMessage.load("large_attachment.msg")) {
...
}

Code sample:

public final void test()
{
    for (int i = 0; i < 10; i++) {
        System.out.println(i + " iteration");
        try (MapiMessage msg = MapiMessage.load("large_attachment.msg")) {
            System.out.println(msg.getSubject());
            System.out.println(msg.getAttachments().get(0).getSize());
        }
    }
}
13

@jmuth
We have opened the following new ticket(s) in our internal issue tracking system and will deliver their fixes according to the terms mentioned in Free Support Policies.

Issue ID(s): EMAILJAVA-35231

You can obtain Paid Support Services if you need support on a priority basis, along with the direct access to our Paid Support management team.

14

Thank you for the update - I believe this has also been linked to a paid support ticket.

15

Hello @jmuth ,

Yes, it has also been linked to a paid support ticket.

16

Hello @jmuth,

You can load a message with MsgLoadOptions.LeaveOpen option to optimize memory usage:

MsgLoadOptions lo = new MsgLoadOptions();
lo.setLeaveOpen(true);
try (MapiMessage m = MapiMessage.load("large_attachment.msg", lo)) {
    System.out.println(m.getAttachments().get(0).getFileName());
    System.out.println(m.getAttachments().get(0).getDisplayName());
    m.getAttachments().get(0).save("att.dat");
}
17

Thank you, Sergey, we’ll give it a try.

18

Hello @jmuth ,

After you try, please spare a minute to share your feedback.

19

So with the sample file we provided, although the file has an “msg” file extension, internally the file is an “eml” and needs to be loaded using EmlLoadOptions. Since there does not appear to be an equivalent “setLeaveOpen” property for EmlLoadOptions, this suggestion may prove helpful for some actual “msg” files but doesn’t help in the case of our sample file which is an “eml”.

Thank you for investigating. We are continuing to look at this ourselves.

20

Hello @jmuth ,

Thank you for your feedback. We will consider this issue.

21

We are seeing the OutOfMemoryError still happening with Aspose.Email 25.4 and a 1GB msg file. Used the following code:

MsgLoadOptions msgLoadOptions = new MsgLoadOptions();
msgLoadOptions.setPreserveEmbeddedMessageFormat(true);
MailMessage mailMessage = MailMessage.load(valueOf(filePath), msgLoadOptions);

stacktrace:
java.lang.OutOfMemoryError: Java heap space
at com.aspose.email.system.io.MemoryStream.(Unknown Source)
at com.aspose.email.zui.a(SourceFile:351)
at com.aspose.email.zui.c(SourceFile:508)
at com.aspose.email.zui.a(SourceFile:115)
at com.aspose.email.zui.(SourceFile:75)
at com.aspose.email.FileFormatUtil.c(SourceFile:469)
at com.aspose.email.MapiMessage.e(SourceFile:1980)
at com.aspose.email.MailMessage.a(SourceFile:1589)
at com.aspose.email.MailMessage.c(SourceFile:1525)
at com.aspose.email.MailMessage.load(SourceFile:1477)
at com.stormed.processing.flattening.extractor.AsposeMsgExtractor.doExtractWork(AsposeMsgExtractor.java:143)
at com.stormed.processing.flattening.extractor.Extractor.extract(Extractor.java:47)
at com.stormed.processing.flattening.extractor.Extractor.extract(Extractor.java:40)
at com.stormed.processing.flattening.Extract.compressedFile(Extract.java:114)
at com.stormed.processing.flattening.Flattener.extract(Flattener.java:111)
at com.stormed.processing.ProcessingMain.extractAttachments(ProcessingMain.java:1033)
at com.stormed.processing.ProcessingMain.flattening(ProcessingMain.java:978)
at com.stormed.processing.ProcessingMain.extraction(ProcessingMain.java:494)
at com.stormed.processing.ProcessingMainTest$$Lambda/0x000001772b112260.execute(Unknown Source)
at org.junit.jupiter.api.AssertDoesNotThrow.assertDoesNotThrow(AssertDoesNotThrow.java:49)
at org.junit.jupiter.api.AssertDoesNotThrow.assertDoesNotThrow(AssertDoesNotThrow.java:36)
at org.junit.jupiter.api.Assertions.assertDoesNotThrow(Assertions.java:3199)
at com.stormed.processing.ProcessingMainTest.processingAndExtraction(ProcessingMainTest.java:475)
at java.base/java.lang.invoke.DirectMethodHandle$Holder.invokeSpecial(DirectMethodHandle$Holder)
at java.base/java.lang.invoke.LambdaForm$MH/0x000001772b191000.invoke(LambdaForm$MH)
at java.base/java.lang.invoke.Invokers$Holder.invokeExact_MT(Invokers$Holder)
at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invokeImpl(DirectMethodHandleAccessor.java:153)
at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
at java.base/java.lang.reflect.Method.invoke(Method.java:580)
at org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:775)
at org.junit.platform.commons.support.ReflectionSupport.invokeMethod(ReflectionSupport.java:479)
at org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)

22

Hello @jwisniewski,

Please note that message classes are in Aspose.Email is designed for standard email sizes. When working with very large .msg files (e.g., 1GB), the full in-memory load and MIME transformation can lead to excessive memory use. Such file sizes are uncommon in email workflows, which typically deal with much smaller messages to ensure compatibility with mail protocols.