On Jan 7, 4:04 am, Chunlei  Wu <reill...@gmail.com> wrote:
> Thanks a lot Graham. I will upgrade my modwsgi to v2.3. Looking
> forward to the v3.0 to see if the fix on issue #29 will fix my problem
> as well.

Actually, my reference to issue #29 is a bit wrong. That issue relates
to connection being closed when trying to write the response. In your
case the issue is when connection is closed or has a problem when
reading the response. The reduction in unnecessary logging in that
issue will not change what you are seeing. When a read fails you will
still see an exception being raised and if your code or Django isn't
doing anything specifically about that and just passing it back, you
will get the same behaviour as you do now.

Graham

> Chunlei
>
> On Jan 5, 3:40 pm, Graham Dumpleton <graham.dumple...@gmail.com>
> wrote:
>
> > On Jan 6, 4:41 am, Chunlei  Wu <reill...@gmail.com> wrote:
>
> > > Hi,
>
> > >        We have a web app running on Django 1.0 / modwsgi 2.0 / Apache
>
> > Latest mod_wsgi is 2.3, you should really think about upgrading. :-)
>
> > > 2.2.3. Sparsely, about 2~3 times a week, I receive emails about
> > > IOError as below:
>
> > > ...
> > >   File "/projects/prod/python/2.5.1/lib/python2.5/site-packages/django/
> > > core/handlers/wsgi.py", line 69, in safe_copyfileobj
> > >     buf = fsrc.read(min(length, size))
>
> > > IOError: request data read error
>
> > > Mostly it happens on the root URL, but there is a case from other URL.
> > > I suspect that it is related to the network connection problem, but I
> > > can not re-produce it. Can anybody explain what  doe this error mean
> > > exactly? Thanks.
>
> > It means that low level Apache functions returned an error when trying
> > to read request content.
>
> > Unfortunately, the particular Apache function used to get the request
> > content is one that effectively looses the even lower level Apache
> > error number which would be useful in qualifying what caused the
> > problem. In other words, the Apache function just says there was an
> > error and not what it was. Technically some different set of Apache
> > functions could be used to do the same thing, without loss of the
> > error code when a problem does occur, but that is a bit trickier and
> > involves more work. Changing how it is done might occur, but not soon.
>
> > More than likely though, it is a variation on another error that can
> > come back when reading request content as described in:
>
> >  http://code.google.com/p/modwsgi/issues/detail?id=29
>
> > That one can occur when user/client aborts the connection. This can
> > occur when they are trigger happy on the reload button.
>
> > To try and reproduce it, perhaps perform a file upload and before it
> > has completed keep pressing the reload button for the page.
>
> > Graham
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to