Hello
When I’m trying to add a MapiMessage message with a big attachment (~400Mb) via
PersonalStorage pst = PersonalStorage.create(%outputStream%, 0);
pst.getRootFolder().getSubFolder(%folderName%).addMessage(message);
this method sometimes (very rarely) gets stuck while loading one of the CPU cores to 100%.
Every time I was adding the same attachment.
Please, let me know what could be the problem here.
Thanks!
UPD: I’ve found a way to reproduce it. And looks like there’s a bigger problem underneath.
Here’s a screenshot of the memory usage on my machine (max is 24Gb):
imageedit_10_4681932765.gif (24.0 KB)
Here’s piece of code that’s executed in a loop:
MapiMessage message = convert(%input[i]%);
pst.getRootFolder().getSubFolder(%folderName%).addMessage(message);
The first line corresponds to the changes in memory, that are marked with green circles.
The second line corresponds to the changes in memory, that are marked with red circles.
(I was using breakpoints, that’s why there are delays between green and red circles)
Each message has an attachment that is ~400Mb.
As you can see, addMessage() method uses a huge amount of memory comparing to the real size of message. Looks like there’s a lot of memory leaks.
The last long red oval marks the place, where we’re stuck inside addMessage() method. Garbage collector is trying to free the memory (which causes high CPU usage) for the method to proceed. I think that this method should throw some exception after some time and not just hang till the app dies with OutOfMemory.
What are your thoughts on this issue?
Thanks!
UPD2: I have one more concern about PersonalStorage being created from outputstream.
I can see that the whole pst file is being stored in memory till it’s formed.
Isn’t it possible to write to the ouputstream the messages that are added before we invoke dispose on PersonalStorage? So that way we won’t have the whole pst file in memory.
Thanks!
We have investigated the memory issue and found that the issue is with big attachment, the server may not be supporting such large attachments. We have logged this issue with ID “EMAILJAVA-34455” for further investigation.
Regarding keeping whole PST file in memory until it is formed, we have logged this as well with ID “EMAILJAVA-34456” for further investigation.
You will be informed here once we have more information to share regarding these logged IDs.