tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Szynol <pj...@columbia.edu>
Subject Re: [OT] FileUploadBase$IOFileUploadException
Date Thu, 02 Sep 2010 18:35:04 GMT

Hey, Chris,

Thanks for your note.

java.io.tmpdir has the same value as the temp dir set up in catalina.sh, 
which is a subdirectory of Tomcat, and which Tomcat is permitted to 
access (r and w).

Your point about writing to disk twice is well taken.  As far as I can 
tell, fileupload doesn't give you a handle to the tmp file, but I'll 
take a closer look to see if there is a way to utilize the stored data 
before it's deleted--that would speed things up indeed.

Thanks for the suggestion.

Best wishes,
Paul


On 9/2/10 10:43 AM, Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Paul,
>
> On 9/1/2010 11:27 PM, Paul Szynol wrote:
>> I checked the temp directory in catalina.sh and also by adding this line
>> to the the ContextListener class:
>>
>>          System.out.println("Temp dir: "
>>                  + (event.getServletContext()
>>                          .getAttribute("javax.servlet.context.tempdir"))
>>                          .toString());
>>
>> The latter is a subdirectory of the former; Tomcat has read/write access
>> to both places.
> You didn't mention what the former and latter are ;)
>
> Again, unless you configure commons-fileupload to use Tomcat's tempdir,
> it'll default to java.io.tmpdir, which you didn't report. What is that
> set to?
>
>> I do create a temporary local copy of the image on disk (by using
>> native Java IO classes), so I am able to access the file system
>> without a problem (ultimately, the images are stored in a database).
> If commons-fileupload is willing to store the file on the disk for you,
> why not let it do that and provide an InputStream to your db-writing
> code? Otherwise, you might end up writing the same file to the disk
> /twice/ before putting it into the database (and back to the disk a
> third time).
>
>> It looks like fileupload is meant to store a temporary version of the
>> image during the upload, presumably to minimize memory usage.
> I believe so. Under a certain size, it will just use memory and leave
> the disk alone.
>
>> This is where the fail is happening, if the image exceeds the
>> threshold size.  I've monitored both temporary directories during the
>> upload, and indeed nothing is being written to them.
> Can you post your code for commons-fileupload usage? That might help.
>
>> I guess I can increase the threshold size to a higher value to prevent
>> the exception by avoiding the file system write altogether, but I worry
>> that if the application has many users uploading large images
>> concurrently, this set up will quickly lead to fatal out of memory
>> errors. :(
> Exactly why this feature exists. ;) You could also limit the number of
> simultaneous uploads, and then make sure your upload concurrency limit *
> maximum image size is affordable under your memory constraints.
>
>> I've sent an inquiry to the apache commons user mailing list.  I will
>> follow up here when I hear back.
> Sound good.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkx/uBMACgkQ9CaO5/Lv0PDCEwCfUJ0S+oTiLCujI5NLIxk1Awel
> iAYAn08cN5LCkmshK4AseeEPPKg+4/gG
> =hgED
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message