On Oct 9, 8:12 am, Trey <[EMAIL PROTECTED]> wrote: > 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)
For the purposes of Python web applications which support the WSGI interface, such as Django, then mod_wsgi is a viable replacement for mod_python. In some respects, mod_wsgi is also a viable replacement for FASTCGI solutions in many cases as mod_wsgi supports both an embedded mode (like mod_python) and a daemon mode (like FASTCGI). The only feature I know of missing in mod_wsgi 1.X that some Django people like to use from mod_python is the ability to define an Apache authentication handler in mod_python so for example they can use Django user authentication for authenticating users accessing a Trac instance. This ability to define an Apache authentication handler, as well as group authorisation has already though been implemented for mod_wsgi 2.0 and is available from Subversion repository trunk for mod_wsgi. In respect to mod_wsgi relating to development server, the only thing I can think of that you are talking about here is how I might have previously indicated how mod_wsgi could easily be used in situations where needing to support multiple developers working on the same Django application but where each has its own workspace. Yes mod_wsgi can help in this situation, but this is just an outcome from its flexible configuration options in providing both embedded and daemon modes. For production sites mod_wsgi is more than capable and it shouldn't be seen as only useful for development environments. Graham > 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 -~----------~----~----~----~------~----~------~--~---
