Re: That pesky Amount read didn't match content-length ...
Re: That pesky Amount read didn't match content-length ...
- Subject: Re: That pesky Amount read didn't match content-length ...
- From: ocs--- via Webobjects-dev <email@hidden>
- Date: Thu, 13 Feb 2025 20:02:07 +0100
Well I couldn't easily try the streamed upload, for it requires a single-action
form; nevertheless I have tried streamToFilePath — with precisely the same
outcome as normal upload :(
> On 13. 2. 2025, at 13:20, OCsite via Webobjects-dev
> <email@hidden> wrote:
>
> Thanks!
>
>> On 13. 2. 2025, at 12:49, Hugi Thordarson via Webobjects-dev
>> <email@hidden> wrote:
>> Sorry, then I'm kind of out of ideas.
>
> Makes two of us :)
>
>> My first thought was that the adaptor logging was accurate and that the
>> application's adaptor configuration was set up so that the file upload
>> request actually times out. But creating a simple file upload page and
>> setting all the adaptor timeouts to a short period didn't replicate your
>> issue — the exception that gets logged in that case is gool ol'
>> "SoketException: Broken pipe".
>
> Far as I know, there's one way to replicate it: start a big upload, and
> before it finishes, break it at the browser side (eg in Safari by the × at
> the right side of the address field). In my experience, this reliably causes
> “Amount read didn't match content-length”.
>
> Which though is just as expected in this case and does not help at all with
> the problem when this happens _without_ breaking the upload at the client
> side. Besides it does not cause marking the instance as dead (which is bogus;
> the instance runs all right, and a subsequent attempt to contact it works
> normally).
>
>> Are you using a regular old WOFileUpload with "data" and "filePath" bindings
>
> Yep.
>
>> or are you using other/streaming bindings?
>
> Good idea — I'll try that, in a vain hope it might help :)
>
>> I can test this again with streaming if that turns out to be your case
>> (performing a 300MB upload with the odl style bindings and timeouts properly
>> set works fine for me through the Apache adaptor).
>
> Actually I don't think you should be able to repeat the problem. I suspect it
> would be related to some setting or specific site condition. I am pretty sure
> I've successfully uploaded much bigger files on another site into the same
> application.
>
> Thanks a lot,
> OC
>
>>
>> Cheers,
>> - hugi
>>
>>
>>> On 13 Feb 2025, at 11:17, OCsite <email@hidden> wrote:
>>>
>>> Hugi,
>>>
>>>> On 13. 2. 2025, at 9:55, Hugi Thordarson via Webobjects-dev
>>>> <email@hidden> wrote:
>>>> when you say 2 MB, is it possible you mean 2 GB?
>>>
>>> Nope. The file which fails to upload has 2 024 943 bytes.
>>>
>>>> ...
>>>> Is this also a problem in direct connect mode or only if you're going
>>>> through the web server adaptor?
>>>
>>> Direct connect works all right, the problem is only adaptor-side. I've
>>> tried to log adaptor, and perhaps the problem might be this?
>>>
>>> ===
>>> Debug: <WebObjects Apache Module> new translate:
>>> /cgi-bin/WebObjects/CEBOIS.woa/wo/14.2
>>> Info: <WebObjects Apache Module> new request:
>>> /cgi-bin/WebObjects/CEBOIS.woa/wo/14.2
>>> Debug: App Name: CEBOIS.woa/wo/14.2 (6)
>>> Debug: req_allocateContent(): content will be streamed. content length =
>>> 2031013
>>> Info: V4 URL: /cgi-bin/WebObjects/CEBOIS.woa/wo/14.2
>>> Info: Cookie instance 1 from woinst=1; wosid=bYkhovnML9gbkEGcLKmzUw;
>>> routeid_cebois=.cebois_2004; routeid_sd3test=.sd3test_2016;
>>> routeid_ema3=.ema3_2001; routeid_ema=.ema_2010
>>> Info: Selecting specific app instance 1.
>>> Debug: Composed URL to '/cgi-bin/WebObjects/CEBOIS.woa/1/wo/14.2'
>>> Info: New request is POST /cgi-bin/WebObjects/CEBOIS.woa/1/wo/14.2 HTTP/1.1
>>>
>>> Info: Sending request to instance number 1, port 2004
>>> Info: Trying to contact CEBOIS:1 on (2004)
>>> Info: attempting to connect to 127.0.0.1 on port 2004
>>> Info: CEBOIS:1 on (2004) connected [pooled: No]
>>> Debug: sendBuffers(): timed out
>>> Error: error sending request
>>> Error: Failed to send request
>>> Info: Marking instance 1 dead
>>> Warn: Marking 127.0.0.1:1 unresponsive
>>> Debug: connectionAttempts = 1, retries = 0
>>> Info: Reading configuration from
>>> http://localhost:1085/WebObjects/wotaskd.woa/wa/woconfig
>>> Info: attempting to connect to localhost on port 1085
>>> Info: Preparing to read config for host: localhost
>>> Info: New response: HTTP/1.0 200 Apple WebObjects
>>> Debug: Header read: last-modified: Thu, 13 Feb 2025 11:14:38 GMT
>>> Debug: Header read: x-webobjects-loadaverage: 0
>>> Debug: Header read: content-type: text/xml
>>> Debug: Header read: content-length: 332
>>> Info: content-length was set expl.: 332
>>> Error: Request handling error: Did not receive any response from
>>> application. It is possible that the application does not exist, or that
>>> the requested url is incorrect.
>>> ... ...
>>> ===
>>>
>>> Thanks a lot,
>>> OC
>>>
>>>>> On 12 Feb 2025, at 20:06, ocs--- via Webobjects-dev
>>>>> <email@hidden> wrote:
>>>>>
>>>>> Hi there,
>>>>>
>>>>> is there a known cure for the darned “IOException: Connection reset by
>>>>> peer: Amount read didn't match content-length” exception upon a file
>>>>> upload?
>>>>>
>>>>> Started to happening to us lately. Smaller files upload all right, bigger
>>>>> ones (from about 2 MB up) trigger this error. Increasing the Java memory
>>>>> through -Xmx does not seem to help.
>>>>>
>>>>> Thanks!
>>>>> OC
>>>>> _______________________________________________
>>>>> Do not post admin requests to the list. They will be ignored.
>>>>> Webobjects-dev mailing list (email@hidden)
>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>
>>>>> This email sent to email@hidden
>>>>
>>>> _______________________________________________
>>>> Do not post admin requests to the list. They will be ignored.
>>>> Webobjects-dev mailing list (email@hidden)
>>>> Help/Unsubscribe/Update your Subscription:
>>>>
>>>> This email sent to email@hidden
>>>
>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list (email@hidden)
>> Help/Unsubscribe/Update your Subscription:
>>
>> This email sent to email@hidden
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden