When thinking of multipart module I thought about 3 alternatives that can co exit. The first is the simple one that hold the content in memory. The second is one that store the content on file system, (I like the auto switch Nick suggested between the first one and this) The third is a forward only multipart module, where the user is obligate to access the parts according to their order. It is a more complex for users to use since they are obligate to order and they do not get information like number of parts, but this is the best in performance wise since the information is read directly from the socket and not manipulate twice.
I believe it would be best if we provide all, the first and second united (auto switch) and the third for usage where the performance is critical. Thought? --Eli From: Nicholas L Gallardo [mailto:[email protected]] Sent: Thursday, July 23, 2009 5:10 AM To: [email protected] Subject: RE: Streaming support for file upload There's some stuff built into Axiom (data model for Axis2) that we did for streaming multi-part messages over a certain size to disk. Might not be able to use all the code directly, but it can at least be an example of how to do it. -Nick Nicholas Gallardo WebSphere - REST & WebServices Development [email protected] Phone: 512-286-6258 Building: 903 / 5G-016 [cid:[email protected]]"Baram, Eliezer" <[email protected]> "Baram, Eliezer" <[email protected]> 07/22/2009 11:08 AM Please respond to [email protected] To "[email protected]" <[email protected]> cc Subject RE: Streaming support for file upload I see. Sorry, no clean solution till we implement multipart provider :-( --Eli -----Original Message----- From: Jain, Shashank Mohan Sent: Wednesday, July 22, 2009 6:58 PM To: [email protected] Subject: RE: Streaming support for file upload The reason of choosing multi part is that along with the document we need to send an xml contract which is the meta data for the job.. That's the reason it's a multi part Regards Shashank -----Original Message----- From: Baram, Eliezer Sent: Wednesday, July 22, 2009 9:20 PM To: [email protected] Subject: RE: Streaming support for file upload If this is the case, why did you select multipart to be the content-type of the request? You can just use the content-type of the file part as the content-type of the request. The recourse method that implements the HTTP POST method should get InputStream as an input parameter and just write it's content to a file/database/whatever. That way you will have no buffering of the request and no out of memory issues. Regards, Eli -----Original Message----- From: Jain, Shashank Mohan Sent: Wednesday, July 22, 2009 6:33 PM To: [email protected] Subject: RE: Streaming support for file upload Hi Eli, We are using a java client for doing file upload and right now its only one big file we need to support Regards Shashank -----Original Message----- From: Baram, Eliezer Sent: Wednesday, July 22, 2009 8:31 PM To: [email protected] Subject: RE: Streaming support for file upload Hi Shashank Wink does not have multipart providers so I guess it's "if atall". Regarding your use case I have 2 question: 1) are you allow to upload more then one file in a single request? 2) are you using a browser as client? Thanks, Eli -----Original Message----- From: Jain, Shashank Mohan Sent: Tuesday, July 21, 2009 6:42 PM To: [email protected] Subject: RE: Streaming support for file upload Thanks Eli, I will add this as a wish in Jira. The use case is to upload say 1 gb of document in a single request. What I observed in Jboss RestEasy is that their MultiPart Provider was buffering the data and thereby causing the heap to run out of memmory. I am curious as to hos this is handled in Wink if atall.. Regards Shashank -----Original Message----- From: Baram, Eliezer Sent: Tuesday, July 21, 2009 8:53 PM To: [email protected] Subject: RE: Streaming support for file upload Hi Shashank Wink does not have multipart providers yet, worth adding a wish in Jira. I guess your use case is uploading several files in a single request, and you are using the TempFileStorageProvider of mime4j. Since if you upload a single document in a request there isn't a need to buffer the data. Regards, Eli -----Original Message----- From: Jain, Shashank Mohan Sent: Tuesday, July 21, 2009 5:38 PM To: [email protected] Subject: RE: Streaming support for file upload Jboss rest easy support streaming for multipart using mime4j. SO when we send huge documents its not buffered but written to a temporary file store. Does Wink provide such implementation.. Regards Shashank -----Original Message----- From: Snitkovsky, Martin Sent: Sunday, July 19, 2009 11:51 AM To: [email protected] Subject: RE: Streaming support for file upload Hi Shashank, Streaming file upload can be implemented with JAX-RS InputStreamProvider. Not sure how much you are familiar with JAX-RS, but what it means is that you can define Resource method that accepts Http InputStream as method input parameter. What is your use-case for streaming file upload? Regards, --martin -----Original Message----- From: Jain, Shashank Mohan Sent: Sunday, July 19, 2009 7:21 AM To: [email protected] Subject: Streaming support for file upload Do we have plans to support this if not already there. Regards Shashank
