Hi, > > In Axis2/Java case we do write the attachment content directly from > > the InputStream to the File when the attachment size is larger than > > the threshold. This avoids loading the whole attachment to the memory > > at all. > > In this case to find out the attachment size don't you need to do any > mime parsing? How do you find the attachment size with out searching for > the mime boundaries ? Yes.. MIME is a boundary based packaging mechanism and you does not need to specify the length for each of the parts...Even the HTTP content length is not there if the message is chunked.
What we did in Axis2/Java to overcome this is to read the data to a byte[] buffer of up to a certain size (the size threshold). If there are more data available in the mime part (if we have not encountered the boundary yet) then we know this attachment is bigger than the threshold. So we create the temp file, pump the content in the buffer to the file, then pump the rest of the stream to the file.. In this way we do not need to know the size of the attachment upfront.. BTW we do all of the above while we are parsing the MIME message at the MIME parser level.. > > This has the plus point that the attachment size will be > > limited only by the available free space in the Temp Directory.. > > Will that be possible in Axis2/C.. Or is that wat you have in mind :).. > > Yes this is possible. But in Axis2/JAVA we will get a OutOfMemory if we parse a large MIME part upfront, since it reads the attachment to memory. May be you can have a larger limit with C than in Java, but ultimately you'll come to a situation where you will not have enough memory to store that MIME part in memory in the parsing time, unless you write in to a File while parsing,.. thanks, Thilina > > > > > > > thanks, > > Thilina > > > > >and keeping the file name inside > > > data_handler instead of the whole buffer. So the service or the client > > > will get the file name instead of the buffered stream, when it receives > > > an attachment. This will not prevent buffering the attachment at the > > > transport but will prevent keeping it inside the om_tree till it reaches > > > the receiver. > > > > > > Before implementing this I would like to know your suggestions regarding > > > this. > > > > > > [1] https://issues.apache.org/jira/browse/AXIS2C-672 > > > > > > Thanks, > > > -Manjula > > > > > > -- > > > Manjula Peiris: http://manjula-peiris.blogspot.com/ > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Thilina Gunarathne - http://thilinag.blogspot.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
