Well, that sounds reasonable. The traffic to my site should (hopefully) be growing over the next few months--I'll just wait and see if it happens more often. I guess if the users aren't getting an error message (and thus thinking that there's something wrong with the site, or that they did something wrong,) then I'm not too worried about it. I guess I won't know what they see until it happens to me, though :-)
Thanks for your help, Jeff On May 25, 6:59 am, Graham Dumpleton <graham.dumple...@gmail.com> wrote: > On May 25, 4:53 am, Jeff FW <jeff...@gmail.com> wrote: > > > Thanks for your response. Sorry I didn't respond earlier--been quite > > busy. > > > I don't know for certain that anyone's seeing a 500 response--I get an > > e-mail from Django (traceback below) and an error in the Apache logs > > (below). I've never received an actual error report from a user (and > > most of my users aren't the most technically inclined...) so I don't > > know what they see. > > > I've never been able to duplicate this myself; it happens on average > > once or twice a week, although it seems to occasionally happen to the > > same person a couple of times within the span of a few minutes. Also, > > mod_wsgi is configured in daemon mode, with 1 process and 1 thread, if > > that matters. > > If it is only happening once or twice a week, then I wouldn't be > terribly concerned. Clients killing off connections abruptly before > request content received is just one of those things that can happen. > The nature of how WSGI and web applications work generally means that > it is never dealt with cleanly and so you just end up with an > unexpected error. > > Django could try and recognise an IOError on failure to read, but what > is it going to do if it isn't going to propagate the error back. It is > also entirely possible that different WSGI hosting mechanisms may not > always raise an IOError as the WSGI specification doesn't say what > should happen. > > Graham > > > I haven't had a chance to try the debugging recipe you provided yet; > > it's a production site, so I'm rather loathe to mess with it, if I can > > avoid it. Not to say that I won't try that, if it comes to it. > > Thanks. > > > Apache log and traceback (both anonymized): > > > [Sat May 16 21:54:10 2009] [error] [client 75.33.xx.xx] (70014)End of > > file found: mod_wsgi (pid=25650): Unable to get bucket brigade for > > request., referer:https://domain.com/account/store/178/manage/item/create/ > > [Sat May 16 17:54:10 2009] [error] [client 75.33.xx.xx] mod_wsgi > > (pid=18243): Exception occurred processingWSGIscript '/var/www/ > > domain.com/django.wsgi'. > > [Sat May 16 17:54:10 2009] [error] [client 75.33.xx.xxx] IOError: > > client connection closed > > > (ignore the time difference--the server is on GMT, but Django is on > > EST) > > > Traceback (most recent call last): > > > File "/var/lib/python-support/python2.5/django/core/handlers/ > > base.py", line 86, in get_response > > response = callback(request, *callback_args, **callback_kwargs) > > > File "/var/www/domain.com/domain/djangologging/decorators.py", line > > 10, in decorated > > response = func(*args, **kwargs) > > > File "/var/www/domain.com/domain/store/views.py", line 137, in > > random_items_ajax > > if not request.POST or 'count' not in request.POST: > > > File "/var/lib/python-support/python2.5/django/core/handlers/wsgi.py", > > line 169, in _get_post > > self._load_post_and_files() > > > File "/var/lib/python-support/python2.5/django/core/handlers/wsgi.py", > > line 149, in _load_post_and_files > > self._post, self._files = http.QueryDict(self.raw_post_data, > > encoding=self._encoding), datastructures.MultiValueDict() > > > File "/var/lib/python-support/python2.5/django/core/handlers/wsgi.py", > > line 203, in _get_raw_post_data > > size=content_length) > > > File "/var/lib/python-support/python2.5/django/core/handlers/wsgi.py", > > line 69, in safe_copyfileobj > > buf = fsrc.read(min(length, size)) > > > IOError: request data read error > > > <WSGIRequest > > GET:<QueryDict: {}>, > > POST:<QueryDict: {}>, > > COOKIES:{'sessionid': 'xxx'}, > > META:{'CONTENT_LENGTH': '7', > > 'CONTENT_TYPE': 'application/x-www-form-urlencoded; charset=UTF-8', > > 'DOCUMENT_ROOT': '/var/www/domain.com/domain/www', > > 'GATEWAY_INTERFACE': 'CGI/1.1', > > 'HTTP_ACCEPT': '*/*', > > 'HTTP_ACCEPT_ENCODING': 'gzip, deflate', > > 'HTTP_ACCEPT_LANGUAGE': 'en-us', > > 'HTTP_CACHE_CONTROL': 'no-cache', > > 'HTTP_CONNECTION': 'Keep-Alive', > > 'HTTP_COOKIE': 'sessionid=xxx', > > 'HTTP_HOST': 'domain.com', > > 'HTTP_REFERER': 'http://domain.com/page/how_to_sell/', > > 'HTTP_USER_AGENT': 'Mozilla/4.0 (compatible; MSIE 8.0; Windows NT > > 6.0; Trident/4.0; SLCC1; .NET CLR 2.0.50727; .NET CLR 3.0.04506; > > yie8)', > > 'HTTP_X_REQUESTED_WITH': 'XMLHttpRequest', > > 'PATH': '/usr/local/bin:/usr/bin:/bin', > > 'PATH_INFO': u'/ajax/random_items/', > > 'PATH_TRANSLATED': '/var/www/domain.com/django.wsgi/ajax/ > > random_items/', > > 'QUERY_STRING': '', > > 'REMOTE_ADDR': 'xx.xx.xx.xx', > > 'REMOTE_PORT': '50355', > > 'REQUEST_METHOD': 'POST', > > 'REQUEST_URI': '/ajax/random_items/', > > 'SCRIPT_FILENAME': '/var/www/domain.com/django.wsgi', > > 'SCRIPT_NAME': u'', > > 'SCRIPT_URI': 'http://domain.com/ajax/random_items/', > > 'SCRIPT_URL': '/ajax/random_items/', > > 'SERVER_ADDR': 'xx.xx.xx.xx', > > 'SERVER_ADMIN': '[no address given]', > > 'SERVER_NAME': 'domain.com', > > 'SERVER_PORT': '80', > > 'SERVER_PROTOCOL': 'HTTP/1.1', > > 'SERVER_SIGNATURE': '<address>Apache/2.2.9 (Ubuntu) mod_ssl/2.2.9 > > OpenSSL/0.9.8g mod_wsgi/2.3 Python/2.5.2 Server at domain.com Port 80</ > > address>\n', > > 'SERVER_SOFTWARE': 'Apache/2.2.9 (Ubuntu) mod_ssl/2.2.9 OpenSSL/ > > 0.9.8g mod_wsgi/2.3 Python/2.5.2', > > 'mod_wsgi.application_group': 'domain.com|', > > 'mod_wsgi.callable_object': 'application', > > 'mod_wsgi.listener_host': '', > > 'mod_wsgi.listener_port': '80', > > 'mod_wsgi.process_group': 'domain.com', > > 'mod_wsgi.reload_mechanism': '1', > > 'mod_wsgi.script_reloading': '1', > > 'wsgi.errors': <mod_wsgi.Log object at 0x55555878e8d0>, > > 'wsgi.file_wrapper': <built-in method file_wrapper of > > mod_wsgi.Adapter object at 0x5555591e1b70>, > > 'wsgi.input': <mod_wsgi.Input object at 0x55555900ef70>, > > 'wsgi.multiprocess': True, > > 'wsgi.multithread': False, > > 'wsgi.run_once': False, > > 'wsgi.url_scheme': 'http', > > 'wsgi.version': (1, 0)}> > > > Thanks a lot, > > Jeff > > > On May 21, 10:47 pm, Graham Dumpleton <graham.dumple...@gmail.com> > > wrote: > > > > On May 22, 12:31 pm, Jeff FW <jeff...@gmail.com> wrote: > > > > > I've had the same problem, and can't figure out how to resolve it. It > > > > seems to have nothing to do with the amount of data being transfered: > > > > it happens occasionally on the smallest of page requests/responses. > > > > It also doesn't seem to be related to browser, unless several > > > > different versions of IE *and* Safari have the same problem. I tried > > > > disabling keepalives for Safari at least, and it doesn't seem to have > > > > helped. I'd prefer not to disable keepalives in general, if I can > > > > avoid it. > > > > > All of the error messages I've received have shown in the traceback > > > > that they're coming through this > > > > function:http://code.djangoproject.com/browser/django/trunk/django/core/handle... > > > > > It seems to me like there's an easy workaround (I'm sure the actual > > > > fix has to be much lower level, inWSGIor Apache [or even lower]) > > > > that would at least stop my users from getting 500 errors: wrap the > > > > contents of that function in a try block, and *don't* raise the > > > > exception. > > > > > Otherwise, I'd have to wrap every view that uses POST in that, which > > > > would be very annoying. Or maybe write middleware that just peeks at > > > > POST before anything else gets it, so that I could catch it there. > > > > > Thoughts? > > > > If clients are actually see a 500 error response, at least means that > > > return part of socket connection hasn't been closed. Is that want you > > > really meant, or is the 500 error in the logs and clients get a blank > > > page. > > > > If you could duplicate it, which it seems you can't, I would have > > > suggested using second recipe in: > > > > http://code.google.com/p/modwsgi/wiki/DebuggingTechniques#Tracking_Re... > > > > to try and capture request content and response to see how much of the > > > request is actually being received. > > > > BTW, are you using mod_wsgi embedded mode or daemon mode? > > > > Also post an actual example traceback and what errors you get in the > > > Apache error log just to validate the nature of the problem. > > > > Graham > > > > > Thanks, > > > > Jeff > > > > > On Mar 31, 6:40 pm, Graham Dumpleton <graham.dumple...@gmail.com> > > > > wrote: > > > > > > On Apr 1, 1:34 am, akaihola <akaih...@gmail.com> wrote: > > > > > > > We ran into the same issue Chunlei Wu described in January[1]. A > > > > > > user > > > > > > was trying to upload large files and all we got were 500 errors by > > > > > > e- > > > > > > mail: > > > > > > > File > > > > > > "/home/citedesarts/src/django/django/http/multipartparser.py", > > > > > > line 406, inread > > > > > >IOError:requestdatareaderror > > > > > > > The user was on a public library computer with IE7. We're running > > > > > > Apache 2.2.9 andmod_wsgi2.3 as packaged in Debian 5.0 Lenny. > > > > > > > I'm wondering about the HTTP_VIA header, could that have contributed > > > > > > to the problem? > > > > > > The presence of the header itself is not likely to cause the issue, > > > > > but its presence does indicate that therequestwent via a proxy or > > > > > other sort of software. That proxy may have been killing off requests > > > > > which took too long. > > > > > > The basic problem remains that the connection to the HTTP server was > > > > > dropped before alldatacould beread. > > > > > > Graham > > > > > > > [1]http://groups.google.fi/group/django-users/browse_thread/thread/ > > > > > > 946936f69c012d96 > > > > > > > ---- > > > > > > > Below is the WSGIRequest dump from the 500 e-mail: > > > > > > > <WSGIRequest > > > > > > GET:<QueryDict: {}>, > > > > > > POST:<could not parse>, > > > > > > COOKIES:{'sessionid': '83bc617fed936487b17f7d14848d245c'}, > > > > > > META:{'CONTENT_LENGTH': '30977474', > > > > > > 'CONTENT_TYPE': 'multipart/form-data; > > > > > > boundary=---------------------------7d9c0903da', > > > > > > 'DOCUMENT_ROOT': '/home/mysite/media', > > ... > > read more » --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
