tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: [OT] FileUploadBase$IOFileUploadException
Date Thu, 02 Sep 2010 14:43:31 GMT
-----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


Mime
View raw message