Interesting approach Malcom, I will read up on a few of the tools to see if I can catch the error in the act. I have been doing something similar with strace and some sort of segfault that is very hard to catch.
Graham, I haven't researched mod_wsgi much, is it an alternative to mod_python or does it just relate to the development server (as that's the only place I've seen it mentioned) trey On Oct 6, 7:01 pm, Graham Dumpleton <[EMAIL PROTECTED]> wrote: > The way mod_python reads request content is a bit broken and can screw > up in various ways, albeit rarely. This may be another example to add > to the existing ones. The other known examples are: > > http://issues.apache.org/jira/browse/MODPYTHON-212 > http://issues.apache.org/jira/browse/MODPYTHON-234 > > I haven't sat down to try and work out how to fix the code in > mod_python, but being mindful that it was doing the wrong thing, I > completely wrote from scratch in mod_wsgi the input reading code and > didn't rely on the mod_python code in any way. Thus, as far as I know > these problems shouldn't occur with mod_wsgi. > > Graham > > On Oct 7, 2:06 am, Malcolm Tredinnick <[EMAIL PROTECTED]> > wrote: > > > On Sat, 2007-10-06 at 15:20 +0000, Trey wrote: > > > There are other people that have brought this up a little bit some > > > time ago. I run a small to medium sized web application that takes > > > profile pictures. By far my largest customer service issue is people > > > not being able to upload their photos. > > > > For the most part I have played it down as their connection sucking or > > > perhaps doing something stupid with the browser, but there are a > > > couple of things that I am running into that are causing an issue. > > > I internally wince a bit every time this problem comes up. There's > > something going on that makes it occur regularly for certain > > combinations of browsers and servers (there's a report in Edgewall's own > > Trac installation about a repeatable upload problem for one group of > > people that is the same problem -- see [1]). However, it's not easily > > reproducible for other people. > > > [1]http://trac.edgewall.org/ticket/5226 > > > > 1. I can't replicate this, no matter what I do with my browser in the > > > middle of an upload. > > > 2. Judging by the django code near the problem, this is working on > > > information that has already been received. > > > 3. I get this a few times a day at least, different people every time. > > > > If someone with some knowledge of the core or http areas of django > > > could speak up on this I would be very grateful. > > > The error itself appears to be coming from inside mod_python. The > > self._req attribute is mod_python's request object and we're in the > > process of reading data from there. Unfortunately, that doesn't help > > very much with the problem diagnosis, but if you Google around for the > > exact error message, you'll see it appearing in other places as well. > > Just not commonly enough to help work out what's really going on. I > > don't think there's a lot we can do on the Django side to mitigate this. > > > If it was me running a site that had this problem and I was really > > dedicated to solving it, I'd try to put a rolling tcpdump on the > > connection to try and capture the problem live. It will be a real bear > > to try and interpret the results, but if you have accurate > > (synchronised) clocks on all the machines in question and are capturing > > the exception when it happens (with a timestamp), you should be able to > > get close. Tcpdump has the ability to roll the logs after a certain size > > and to create no more than a certain number of log files before reusing > > the first ones (so it can use a ring of files, essentially). And > > remember that it doesn't capture all the packets, only the first few > > bytes -- enough to determine the protocol and see the start of the > > message body. You can tweak this, of course, but the point is you won't > > be capturing *all* of the traffic to your site, so storage requirements > > won't be unmanageably huge (but they will be large). If you can set > > aside a few gigabytes of disk space to capture logs and are able to > > respond reasonably fast when the error occurs (so you can grab the log > > that will contain the error before it gets overwritten next time > > around), this is a viable technique. > > > Unfortunately, it may not tell you a lot (it's always a good idea to > > know what you hope to get out of a major debugging thing like this). You > > might see that either there is a slight hold-up in the client sending > > data and maybe you'll be able to see the browser type in the HTTP > > headers. Or you might see no break in the packet timings at all, which > > says there was a hold up inside application space (Apache, I guess). I'm > > not sure how either piece of information will help much, although > > knowing where to look further will always be a benefit. > > > I guess I'd also try to ensure I was running the latest mod_python (and > > Apache) in cases like this. The code is getting better all the time -- > > you just don't see any huge "I upgrade mod_python and the wheels > > completely fell off my site" problems -- so taking advantage of all the > > bug fixes you can can't hurt here, just in case it is an > > application-layer problem. > > > Please realise that everything I've written here is along the lines of > > how I would go about trying to gather more information. I have no > > special insight into what is causing the problem, although from reading > > a bunch of problem reports on the web, it sounds like it is repeatable > > for certain client setups, so might not be just a sporadic connection > > issue. > > > Regards, > > Malcolm --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
