Hi All, We have been working on cracking the 2.1GB limit for file uploads using WebObjects, and no matter what approach we use, we are hitting an exception like this:
DiskTool DEBUG NSLog (46 appendln) - <com.webobjects.appserver._private.WOHttpIO> Unable to parse content-length header: '2182961242'. DiskTool WARN NSLog (43 appendln) - <WOWorkerThread id=7 socket=Socket[addr=/0:0:0:0:0:0:0:1%0,port=49397,localport=55566]> Exception while creating request: java.lang.IllegalArgumentException: <er.extensions.appserver.ERXRequest>: Can not initialize a WORequest with a null method.; dropping connection [2010-5-18 12:55:50 EDT] <WorkerThread7> java.lang.IllegalArgumentException: <er.extensions.appserver.ERXRequest>: Can not initialize a WORequest with a null method. at com.webobjects.appserver.WORequest.<init>(WORequest.java:242) at er.extensions.appserver.ERXRequest.<init>(ERXRequest.java:61) at er.extensions.appserver.ERXApplication._createRequest(ERXApplication.java:1298) at com.zenn.id.IDApplication._createRequest(IDApplication.java:50001) at com.steeplechase.disktool.Application._createRequest(Application.java:50001) at er.extensions.appserver.ERXApplication.createRequest(ERXApplication.java:1268) at com.zenn.id.IDApplication.createRequest(IDApplication.java:50001) at com.steeplechase.disktool.Application.createRequest(Application.java:50001) at com.webobjects.appserver._private.WOHttpIO.readRequestFromSocket(WOHttpIO.java:380) at com.webobjects.appserver._private.WOWorkerThread.runOnce(WOWorkerThread.java:88) at com.webobjects.appserver._private.WOWorkerThread.run(WOWorkerThread.java:226) at java.lang.Thread.run(Thread.java:637) After decompiling WOHttpIO it appears that the contentLength is still an integer in the WO 5.4.3 version of WOHttpIO. These exceptions appear to happen on the second call to WOHttpIO.readRequestFromSocket where a WORequest is initialized. With files smaller than 2.1 GB everything works fine, anything larger, and we get an immediate exception message. readRequestFromSocket is generally called a second time after the file upload finishes. We have experienced this behavior when using both WOFileUpload and AjaxFlexibleFileUpload, using the following bindings: bufferSize = "$bufferSize" streamToFilePath = "$streamToFilePath" mimeType = "$mimeType" filePath = "$filePath" finalFilePath = "$finalFilePath" We have experienced the same problem when using the StreamActionRequestHandler ( wis ) and getting to the contentStream directly. This is ideally how we would like to handle large files in order to keep the memory requirements as low as possible. Every one of our approaches works beautifully, unless we try to upload gigantic files. Is anyone else uploading anything larger than 2.1 GB using a WebObjects application? Thanks a lot in advance for any pointers or advice! Uli PS: we've tested with an April build of Project Wonder and the latest available Hudson build 85 and experienced the same issue with WO 5.3.3. _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
