struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alec Bau <Alec....@msdw.com>
Subject Re: Volunteer: File Upload/ Multipart form handling
Date Tue, 03 Oct 2000 23:08:35 GMT
> Ouch. That's probably OK for small files, but if someone is uploading a
> large file, or several people are uploading at once, isn't that going kill
> performance, as you eat up all the system's memory?

I was using a limit on file size (5Mb). In any case if you have a big
mutltipart form with file upload you don't want a user to wait
considerable time just to validate a form and report an error that they
missed some obscure but required field. Also reading into memory makes
this phase faster than writing immediately to the disk. For the site
with high probability of many simultaneous uploads you probably will
need to sync   the code or limit concurrent use in any case or invest in
hardware and clustering.

Certainly if you have a simple one file field form with an Upload File
button then you want to go directly to saving file on disk. But then
you'll have nothing to populate and you can simply use any of available
file upload packages in your Action.

I think if we're going to integrate mutltipart stuff in Struts in a
generic way there should be a set of config params (maybe even on a per
form basis) that at least let specify how upload files should be handled
(memory or disk), what's the file size threshold for memory storage,
what's the directory and file name pattern for disk storage, etc. In
case of automatic disk storage there also should be a way to auto
rollback (delete file(s)) in case the form didn't pass validation.


Martin Cooper wrote:
> 
> At 05:24 PM 10/3/00 -0400, Alec Bau wrote:
> >1. At the parsing stage in processActionForm I've chosen to store
> >file(s) contents in *memory* and not write it to file(s). Otherwise if
> 
> Ouch. That's probably OK for small files, but if someone is uploading a
> large file, or several people are uploading at once, isn't that going kill
> performance, as you eat up all the system's memory?
> 
> --
> Martin Cooper
> Tumbleweed Communications

Mime
View raw message