Closed GoogleCodeExporter closed 8 years ago
Is it possible that the file upload handles file content differently according
to the file size?
When a non-sticky session contains a File object and this session is
deserialized on another machine the underlying file (in the filesystem) will
obviously not exist. So the issue you describe sounds reasonable to me. That it
doesn't happen indicates the < 256k file content is saved in memory. So maybe
this threshold is configurable?
Another solution would be to use a shared filesystem (e.g. NFS), so that the
tmp files are available on all machines.
Another alternative would be to store the file content (byte[]) in the session
instead of the File reference.
Original comment by martin.grotzke
on 21 May 2013 at 9:41
I've testing so many times ,
in stricky model,no error ,
only non-stricky model ,when the upload file bigger than 256k ,it happens . file also has uploaded success , but when i request a request ,it happens error such as error.log .
i don't know why it goes to read the tmp file in tomcat temp work space ,is there any way to let the msm don't serialize upload file info, or could you show me where the tmp file created .
other way :
I use only one memcached service , one tomcat service.
thanks !
Original comment by liqiumen...@gmail.com
on 21 May 2013 at 10:10
I cannot add much to my initial comment. Have you read / understood it?
The file is created as tmp file by your file upload library, and the File
object references this path. When a session is handled by tomcats on different
machines (without shared file system where tmp files are stored) this obviously
leads to issues.
What do you mean with "I use only [..] one tomcat service." - does it mean that
you have only one tomcat instance handling requests?
Original comment by martin.grotzke
on 21 May 2013 at 1:09
sorry,
yes ,it's mean only one tomcat instance handling requests
Original comment by liqiumen...@gmail.com
on 22 May 2013 at 12:30
Ok, that this happens with 1 tomcat sounds weird. Though, I don't think it
makes sense to invest time to find out why this happens.
I suggest
a) you serialize the file in a different way (store raw bytes in the session) or
b) explicitely store the file in a defined location (e.g. database, S3 etc.)
and only store the file reference (e.g. db id) in the session
If you'd still like to know why you're experiencing the error you should use
debugging to see what's happening.
Original comment by martin.grotzke
on 22 May 2013 at 8:55
I'm under high workload,there is no time to find out why this happens,
thanx for your suggestion ,
I modify the org.apache.commons.fileupload.disk.DiskFileItem class of
commons-fileupload-1.2.jar ,add an exception catch and process , and it
works.
Original comment by liqiumen...@gmail.com
on 22 May 2013 at 3:15
Great it works!
Original comment by martin.grotzke
on 22 May 2013 at 8:40
Original issue reported on code.google.com by
liqiumen...@gmail.com
on 21 May 2013 at 8:55Attachments: