Hello Tony, this threshold is used by apache.commons upload for memory/disk caching of uploaded files, I think (and as such is normally lower than maxpostsize).
Some investigations to be sure: In Java if any int result exceeds the upper limit the result should be always -1, as in Java the endianes is always the same (The JVM Spec indicates: Multibyte data items are always stored in big-endian order, http://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.html) and ant in is a signed integer, and as such, when the most significant bit is 1 it becomes a negative, e.g. for a signed byte: -1 == 11111111 using 2´s -complement operation: http://en.wikipedia.org/wiki/2%27s-complement. I think streams above this limit could be handled, but this requires code changes... Best regards, Georg Von: Tony Oslund <[email protected]> An: Turbine Users List <[email protected]>, Datum: 16.01.2013 18:15 Betreff: Re: Antwort: upload file size limit Hello Georg, It has been a long time since I looked at this problem (literally years), but I noticed the following note in my own settings. Perhaps this will help. # Set the following small so that files are written directly to disk (not cached in memory) services.UploadService.size.threshold=10 Tony On 1/14/2013 4:18 AM, Georg Kallidis wrote: > this seems to be a general problem, see > > http://stackoverflow.com/questions/7423285/javax-servlet-httpservletrequest-getcontentlength-returns-int-only . > > The code in > org.apache.turbine.services.upload.TurbineUploadService.parseRequest > (Turbine Version 2.3.3) is: > > int requestSize = req.getContentLength(); > if (requestSize == -1) -> your exception > > and as int has a max value of > 2,147,483,647 (inclusive) = 2GB -1 > > and your content-length: > 3097243346 > > (in bytes) is above this limit Turbine probably could not handle this I > am afraid .... > > > Best regards, Georg > > > > > Von: Torsten Rohlfing <[email protected]> > > An: [email protected], > > Datum: 14.01.2013 08:43 > > Betreff: upload file size limit > > > > > > > Hi - > > I am using a piece of server software (XNAT; http://xnat.org) that > internally uses turbine to provide a file upload service. > > When I try to upload files larger than about 1GB, the upload fails. > Smaller files upload without problems. Also, the large-file uploads fail > > right away, so this is not a timeout problem.) > > I have already put 'maxPostSize="0"' into all Connector entries in my > /etc/tomcat/server.xml file (using Tomcat7), and I have also adjusted > "services.UploadService.size.max" in the deployed > TurbineResources.properties file. > > Still, large file uploads fail and I see the following error messages in > > the turbine.log file: > > 2013-01-11 16:00:27,490 [http-bio-8080-exec-14] ERROR > org.apache.turbine.util.parser.DefaultParameterParser - File upload > failed > org.apache.turbine.util.TurbineException: the request was rejected > because it's size is unknown > at > org.apache.turbine.services.upload.TurbineUploadService.parseRequest > (TurbineUploadService.java:210) > at > org.apache.turbine.services.upload.TurbineUpload.parseRequest > (TurbineUpload.java:144) > .... [shortened here] > 2013-01-11 16:00:27,616 [http-bio-8080-exec-14] ERROR > org.apache.turbine.Turbine - Turbine.handleException: > java.lang.Exception: Invalid submit value (POST on URL: > http://localhost:8080/xnat/app/action/ExptFileUpload > <http://localhost:8080/xnat/app/action/ExptFileUpload> from /128.... > <http://128.18.20.155> (40328) user: 0:0:0:0:0:0:0:1 > Headers: > host: localhost:8080 > user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20100101 > Firefox/17.0 > accept: text/html,application/xhtml +xml,application/xml;q=0.9,*/*;q=0.8 > accept-language: en-US,en;q=0.5 > accept-encoding: gzip, deflate > referer: https://... > cookie: JSESSIONID=...; SERVER_RESPONSE_TIME=256.5; server_name=...; > SESSION_TIMEOUT_TIME=1357941855463; SESSION_EXPIRATION_TIMEOUT=false; > SESSION_EXPIRATION_TIME_DIALOG_DISPLAYING=false; WARNING_BAR=OPEN; > SESSION_EXPIRATION_TIME="0,900000"; PHPSESSID=...; authchallenge=... > content-type: multipart/form-data; > boundary=---------------------------14265898961818864561123961800 > x-forwarded-for: 128.x... > x-forwarded-host: ... > x-forwarded-server: ... > connection: Keep-Alive > content-length: 3097243346 > > Cookies: > JSESSIONID ... -1 null > SERVER_RESPONSE_TIME 256.5 -1 null > server_name ... -1 null > SESSION_TIMEOUT_TIME 1357941855463 -1 null > SESSION_EXPIRATION_TIMEOUT false -1 null > SESSION_EXPIRATION_TIME_DIALOG_DISPLAYING false -1 null > WARNING_BAR OPEN -1 null > SESSION_EXPIRATION_TIME 0,900000 -1 null > PHPSESSID ... -1 null > authchallenge ... -1 null > ) > > (I removed potentially confidential-looking stuff and replaced it with > "..."). > > What else might I have to adjust to make turbine accept larger files, or > > where else might I look to get to the bottom of this? > > Thanks very much in advance! > > Torsten > > -- > Torsten Rohlfing, PhD SRI International, Neuroscience Program > Senior Research Scientist 333 Ravenswood Ave, Menlo Park, CA > 94025 > Phone: ++1 (650) 859-3379 Fax: ++1 (650) 859-2743 > [email protected] http://www.stanford.edu/~rohlfing/ > > "Though this be madness, yet there is a method in't" > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
