When receiving incoming messagges SAAJ can utilize MimePull Parser which stores the attachment to file system.
http://weblogs.java.net/blog/kumarjayanti/archive/2009/12/10/summary-proprietary-features-saaj-ri-134
not sure if this will help in this case.
On 09-Aug-2011, at 10:33 PM, Dmitry Katsubo wrote:
> On 08.08.2011 11:36, yann.blazart_at_gmail.com wrote:
>> Hi ! As I ve no responses, I'm writing to the list.
>>
>> I have open a bug http://java.net/jira/browse/JAX_WS-971. As nobody
>> take it, I've writed a post on the forum, but no more response...
>>
>> So, when you modify an outcome message with a Handler, and when you
>> deal with large attachment,you have a problem, because in the classe
>> com.sun.xml.ws.message.saaj.SAAJMessage.SAAJAttachment, we have the
>> following method used by MimeCodec and MTOMCodec :
>>
>> public void writeTo(OutputStream os) throws IOException {
>> os.write(asByteArray());
>> }
>>
>> The document is entirely mounted in memory !
>>
>> Is anybody can make a patch to correct this ?
>
> Strange, that you haven't got OutOfMemory before (or you still haven't
> got it?).
>
> Tracing back the source:
>
> SAAJMessage.SAAJAttachment -> AttachmentPartImpl -> MimeBodyPart, and
> then in constructor we have a choice:
>
> (a) SharedInputStream: Can somehow clone the contents (e.g. in case the
> attachment was saved to file / temporary location)
> (b) any other: ByteOutputStream is created (the contents is completely
> in memory).
>
> As SharedInputStream has no implementors, see also the code comment:
>
> // SAAJ doesn't utilize this, but I think it should.
>
> so I suppose (b) is the common case which means attachments are always
> stored in memory.
>
> --
> With best regards,
> Dmitry