bossadvisors / memcached-session-manager

Automatically exported from code.google.com/p/memcached-session-manager
0 stars 0 forks source link

non-sticky upload file bigger than 256k error #163

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago

1. a web project using stuts1.x ,has file upload component
2.linux os with memcached 1.4 server, 
3.tomcat 6 with memcached-session-manager-1.6.0 (either 
memcached-session-manager-1.6.4)
4.configure:
     <Manager  className="de.javakaffee.web.msm.MemcachedBackupSessionManager"
    memcachedNodes="n1:myMemcachedSevice:11221"
    sticky="false"  
    lockingMode ="auto"
    sessionBackupAsync="false"   
    memcachedProtocol="binary"  
    requestUriIgnorePattern=".*\.(ico|png|gif|jpg|css|js|rar|zip)$"      transcoderFactoryClass="de.javakaffee.web.msm.JavaSerializationTranscoderFactory"
    />

5.when i has uploaded a  file bigger than 256k, in next opration ,it  catch 
IOException ,and it seems session has removed,but less then 256k not .

Original issue reported on code.google.com by liqiumen...@gmail.com on 21 May 2013 at 8:55

Attachments:

GoogleCodeExporter commented 9 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

GoogleCodeExporter commented 9 years ago
 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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
sorry,
yes ,it's mean only one tomcat instance handling requests

Original comment by liqiumen...@gmail.com on 22 May 2013 at 12:30

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
Great it works!

Original comment by martin.grotzke on 22 May 2013 at 8:40