On Jun 2, 2009, at 4:28 AM, Ari Heino wrote:
> New (or continue of) issue with this byte [] handlling of input.
> with very
> large files or many concurrent files, java heap space fills up and
> causes
> OutOfMemoryError.
>
> This seems to be because all the bytes are actually read into memory
> with
> this
>
> byte[] bytes =
> multiPart.getBodyParts().get(1).getEntityAs(byte[].class);
>
Yes, because you are using byte[], so the whole body part will be
loaded into memory.
If you want to stream the body part (which will be cached to disk) you
need to do:
InputStream in =
multiPart.getBodyParts().get(1).getEntityAs(InputStream.class);
> Is there a ways to "go around" this reading into memory part while
> using
> MimePull library? What i'm doing with inputstream is saving it into
> database
> via JPA/EclipseLink.
>
The only way to use the MimePull API is to use it within your resource
method, there is currently no support for it. But i think we should
consider a simple streaming-based wrapper around it for accessing
parts as Java types in addition to InputStream (as long as you access
the body parts in order that they are serialized).
Paul.
> --
> View this message in context: http://n2.nabble.com/Multipart-1.0.3-not-finding-message-body-reader-tp2668407p3011538.html
> Sent from the Jersey mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>