Also, I get no errors if I remove the maximum-requests
On Apr 15, 3:45 pm, Alex Robbins <[email protected]>
wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
