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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
