There is likely an issue with how the WOAdaptor is compiled on a particular system. While some people are fine, others are not.
We hit a stability issue similar to yours with file uploads and play back of video files as well. Direct connect was fine but the adaptor on the Linux server was getting messed up. In our case, we gave up and decided to side step the problem. We removed the wo adaptor entirely. We then used Apache’s built in reverse proxy. There was a WOWODC session about how to do this. At the time, the presenter did it because Apple OS update removed the WOAdaptor but I think it’s likely a good idea in general these days. One less non-standard thing to worry about. No longer need to compile it, etc. > On Feb 13, 2025, at 8:20 PM, ocs--- via Webobjects-dev > <webobjects-dev@lists.apple.com> wrote: > > Hugi, > > well I can't say I _entirely_ understand the behaviour (probably would have > to analyse and understand the adaptor code first), but my testing sort of > suggests that > > (i) the culprit is too long a computation in the takeValuesFromRequest phase > > I've tried to prolong it artificially first, but it did not cause the > problem. Looks like that if there's just a Thread.sleep, it still works. > Probably in this case the application is still responsive enough, but when > computing heavily instead, it is not. > > (ii) when the uploaded file size extends some threshold, the adaptor seems to > try to contact the application during this phase, does not get answer in > time, and goes the > > === > Debug: sendBuffers(): timed out > Error: error sending request > Error: Failed to send request > Info: Marking instance 1 dead > === > > routine. This happens at a couple of seconds of takeValuesFromRequest. If > takeValuesFromRequest is considerably shorter (or long, but just due a > Thread.sleep), this problem never occurs regardless the upload size (well > tested just up to about 75 MB :)) > > This part I do not quite get: it sort of seems the longer the uploaded file, > the sooner tries the adaptor to contact the application, which does not seem > to make sense to me. > > Anyway, the answer is never allow the takeValuesFromRequest phase to get too > long (and computation-heavy), which I should be able to fix with some smart > caching. > > Thanks a lot for all the help! > OC > > >> On 13. 2. 2025, at 20:02, ocs--- via Webobjects-dev >> <webobjects-dev@lists.apple.com <mailto:webobjects-dev@lists.apple.com>> >> wrote: >> >> 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 >>> <webobjects-dev@lists.apple.com <mailto:webobjects-dev@lists.apple.com>> >>> wrote: >>> >>> Thanks! >>> >>>> On 13. 2. 2025, at 12:49, Hugi Thordarson via Webobjects-dev >>>> <webobjects-dev@lists.apple.com <mailto:webobjects-dev@lists.apple.com>> >>>> 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 <o...@ocs.cz <mailto:o...@ocs.cz>> wrote: >>>>> >>>>> Hugi, >>>>> >>>>>> On 13. 2. 2025, at 9:55, Hugi Thordarson via Webobjects-dev >>>>>> <webobjects-dev@lists.apple.com <mailto:webobjects-dev@lists.apple.com>> >>>>>> 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 >>>>> <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 >>>>>>> <webobjects-dev@lists.apple.com >>>>>>> <mailto:webobjects-dev@lists.apple.com>> 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 (Webobjects-dev@lists.apple.com >>>>>>> <mailto:Webobjects-dev@lists.apple.com>) >>>>>>> Help/Unsubscribe/Update your Subscription: >>>>>>> https://lists.apple.com/mailman/options/webobjects-dev/hugi%40karlmenn.is >>>>>>> >>>>>>> <https://lists.apple.com/mailman/options/webobjects-dev/hugi%40karlmenn.is> >>>>>>> >>>>>>> This email sent to h...@karlmenn.is <mailto:h...@karlmenn.is> >>>>>> >>>>>> _______________________________________________ >>>>>> Do not post admin requests to the list. They will be ignored. >>>>>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com >>>>>> <mailto:Webobjects-dev@lists.apple.com>) >>>>>> Help/Unsubscribe/Update your Subscription: >>>>>> https://lists.apple.com/mailman/options/webobjects-dev/ocs%40ocs.cz >>>>>> <https://lists.apple.com/mailman/options/webobjects-dev/ocs%40ocs.cz> >>>>>> >>>>>> This email sent to o...@ocs.cz <mailto:o...@ocs.cz> >>>>> >>>> >>>> _______________________________________________ >>>> Do not post admin requests to the list. They will be ignored. >>>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com >>>> <mailto:Webobjects-dev@lists.apple.com>) >>>> Help/Unsubscribe/Update your Subscription: >>>> https://lists.apple.com/mailman/options/webobjects-dev/ocs%40ocs.cz >>>> <https://lists.apple.com/mailman/options/webobjects-dev/ocs%40ocs.cz> >>>> >>>> This email sent to o...@ocs.cz <mailto:o...@ocs.cz> >>> >>> _______________________________________________ >>> Do not post admin requests to the list. They will be ignored. >>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com >>> <mailto:Webobjects-dev@lists.apple.com>) >>> Help/Unsubscribe/Update your Subscription: >>> https://lists.apple.com/mailman/options/webobjects-dev/ocs%40ocs.cz >>> <https://lists.apple.com/mailman/options/webobjects-dev/ocs%40ocs.cz> >>> >>> This email sent to o...@ocs.cz <mailto:o...@ocs.cz> >> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com >> <mailto:Webobjects-dev@lists.apple.com>) >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/webobjects-dev/ocs%40ocs.cz >> <https://lists.apple.com/mailman/options/webobjects-dev/ocs%40ocs.cz> >> >> This email sent to o...@ocs.cz <mailto:o...@ocs.cz> > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list (Webobjects-dev@lists.apple.com > <mailto:Webobjects-dev@lists.apple.com>) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/webobjects-dev/aaron%40chatnbike.com > <https://lists.apple.com/mailman/options/webobjects-dev/aaron%40chatnbike.com> > > This email sent to aa...@chatnbike.com <mailto:aa...@chatnbike.com>
_______________________________________________ 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: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
