I am seeing this same error. I tried a little bit of experimentation. Does this give you any clues as to what might be happening?
I wrote a script that runs through the same list of urls (58) on my site. Every run produces different errors and different numbers of errors, but some setups seem more error prone than others. WSGIDaemonProcess project threads=2 maximum-requests=1 17 errors WSGIDaemonProcess project threads=1 maximum-requests=1 0 errors WSGIDaemonProcess project threads=2 maximum-requests=10 4 errors WSGIDaemonProcess project threads=2 maximum-requests=100 0-1 error Depending on the run. WSGIDaemonProcess project threads=20 maximum-requests=10 11 errors WSGIDaemonProcess project threads=20 maximum-requests=1 29 errors and also 4 404s ??? Thanks, Alex On Mar 19, 12:58 am, Graham Dumpleton <[email protected]> wrote: > 2009/3/19 Graham Dumpleton <[email protected]>: > > > > > 2009/3/19 Pete <[email protected]>: > > >> On Mar 18, 3:35 pm, Graham Dumpleton <[email protected]> > >> wrote: > > >>> This is not an error from mod_wsgi but from Django and has been > >>> encountered by various people and not just with mod_wsgi. > > >> Thanks Graham. I dug through a number of Django references before > >> posting here. I'm on Django 1.0.X so Django ticket #8221 has been > >> fixed and you'll notice that no arguments are being sent to the > >> reverse (as expected) so it is not a regex urlresolver issue. I can > >> view the same page w/ the same content hundreds of times without > >> having an issue, but every day or 2 I get the error. > > >> The reason I bring it up here is that the only common thread I can > >> find is the mod_wsgi activity in my Apache error log (pasted in the > >> original email) about it loading the wsgi script at the same time the > >> error occurs. Does mod_wsgi reload the script when 500s are > >> encountered? > > > No. > > > But, by your configuration you have: > > > maximum-requests=500 inactivity-timeout=600 > > > This means the daemon processes are restarted every 500 requests. This > > is a quite low value and wouldn't recommend it. One would only even > > use this option if your application has a problem with memory leaks, > > either explicit or through a poorly written caching system. So, why > > are you usingmaximum requestsoption? > > > The inactivity timeout would only kick in after 10 minutes of no > > requests at all and if your application is used a lot, in practice > > shouldn't ever occur. What was your reasoning for setting the > > inactivity timeout? > > >> If not, is it possible for unexpected behavior to occur > >> if we try to access the app during the wsgi script load process? > > > No, not at least due to an access occurring while the reloading is > > happening, as requests will just be queued. > > > Your problem could be though that you are missing a required import > > dependency. That is, something which maps strings to module/functions > > is being triggered without the module it requires to work not having > > been imported. It may work later in the life of the process because > > something has as a side effect later imported it. Thus you have an > > ordering issue and whether things works depends order URLs are > > requested. I give imports here as a possibility, may it may be some > > other form of initialisation. > > BTW, one way of checking for whether it is an issue with the order in > which URLs are visited, is to use: > > WSGIDaemonProcess project processes=5 threads=1maximum-requests=1 > > It may be slow, but it will result in every request being handled in > new process, ie., CGI like. Use your application and see if you hit a > specific URL which consistently fails with the error. That is, it is > showing you problem URLs whose environment isn't set up properly for > them to run properly. > > Graham --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "modwsgi" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en -~----------~----~----~----~------~----~------~--~---
