Re: problem with WOFileUpload
Re: problem with WOFileUpload
- Subject: Re: problem with WOFileUpload
- From: Chuck Hill <email@hidden>
- Date: Fri, 24 Mar 2006 10:14:32 -0800
Hi,
On Mar 23, 2006, at 6:42 AM, Jean-François Veillette wrote:
Thanks Chuck !
I like the proxy idea, we where thinking something around netstat,
but a proxy might be better. We will ask our admins to take a look.
Further information :
- yesterday, trying to debug the apache configuration, we realized
that we where not using the apache-wo adaptor at all, we where
using the cgi-bin adaptor. Last night, we reconfigured the server
properly, we will see today how it goes with an optimized adaptor.
I doubt this will help. We have seen the same error with the
mod_webobjects adaptor.
- yesterday, we created /tmp/logWebObjects to get adaptor logs, we
didn't have any failure during the day. But users reported that
the application was slower than usual (expected).
That is an interesting outcome. It certainly suggests a problem with
the adaptor.
- yesterday, we tried as much as we could, but where not able to
reproduce the problem.
- The test that I mentionned earlier (original post) where we where
able to reproduce the problem with FF and IE, I have to add that
the 2 sessions where not on the same application instance, FF was
on one app instance and IE on another. So unless real users where
concurent with either one, this lead us to think that it's not
application related, but network/apache related.
- When the user hit this problem, it receive an application not
available page (returned by the adaptor when the application is not
responding). We do not know the sequence, which come first (upload
stream failure first, or app not responding first).
I have not seen a connection between those. Are you running multiple
instances?
- Our users are on PC/IE (not sure exactly which version but a
recent one). But we where able to get the error internally with
Safari/FF.
There goes that idea. :-)
Another thing to try is FastCGI. I think that there is an adaptor
for this in Project Wonder. Perhaps that one does not have this bug?
Chuck
Le 06-03-22, à 22:38, Chuck Hill a écrit :
Hi,
On Mar 22, 2006, at 11:16 AM, Jean-François Veillette wrote:
Situation :
We have an application where users can submit files to the
system. We use WOFileUpload to stream the file directly to the
disk.
There is at least 500 files uploaded per day (up to 1000),
counting for something between 100Mb and 150Mb of data.
Problem :
Every day, we get about 2 to 5 upload that fails with :
Error writing to output stream: java.io.FileOutputStream@6de8a7
java.io.IOException: Connection reset by peer: Amount read didn't
match content-length
I have seen that a lot in my applications that do uploads and I
had always thought it was the user clicking stop, closing the
browser, network interruptions of the upload stream etc.
And at that point, we are looking for tips on where/what to look
to fix the problem.
Here is the Stack on one such problem :
java.lang.RuntimeException: Error writing to output stream:
java.io.FileOutputStream@6de8a7
java.io.IOException: Connection reset by peer: Amount read didn't
match content-length
at
com.webobjects.appserver._private.WOFileUpload.takeValuesFromRequest
(WOFileUpload.java:271)
at
com.webobjects.appserver._private.WODynamicGroup.takeChildrenValuesF
romRequest(WODynamicGroup.java:81)
at
com.webobjects.appserver._private.WODynamicGroup.takeValuesFromReque
st(WODynamicGroup.java:89)
at
com.webobjects.appserver._private.WOConditional.takeValuesFromReques
t(WOConditional.java:41)
at
com.webobjects.appserver._private.WODynamicGroup.takeChildrenValuesF
romRequest(WODynamicGroup.java:81)
...
Server configuration :
On this server, we run both apache 1.x and multiples wo
applications (multiple application and multiple instances) :
WO5.2.3 / Apache 1.x / MacOS-X 10.3.9.
My own impression :
We can reproduce the problem when 2 sessions (one Mac/FireFox,
one PC/IE) tries to upload a file (less than 1 mb each). After a
couple of successful tries (up to 3) we where able to generate
the error.
That is interesting. It seems to rule out my assumptions above.
The "java.io.IOException: Connection reset by peer" part does make
it look as if the app sees a truncated stream.
Does it happen for both browsers or only IE or only FireFox? It
is probably worth putting a proxy between the browser and the app
to see what is getting sent / received.
So this lead me to think about a thread/race condition problem
either on the apache-wo adaptor or in the application
implementation about file upload.
The requests to Apache should be dispatched in their own thread
and the requests into the application are also dispatched into
their own thread. I can't think of where the problem would be in
the application side. I don't know Apache architecture very
well. It could be that there is a race condition when two upload
streams come in at once.
Chuck
http://www.freeiPods.com/?r=21419063
--
Coming in 2006 - an introduction to web applications using WebObjects
and Xcode http://www.global-village.net/wointro
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems. http://www.global-village.net/products/practical_webobjects
_______________________________________________
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