[modwsgi] Re: Intermittent NoReverseMatch errors
They are using different processes, doesn't that separate them?
On May 3, 12:00 am, Graham Dumpleton graham.dumple...@gmail.com
wrote:
If you are receiving requests for same application on both ports, then yes.
Graham
2009/5/2 Alex Robbins alexander.j.robb...@gmail.com:
Sorry this reply took so long, I am in the middle of changing jobs.
Anyway,
WSGIApplicationGroup %{GLOBAL}
does not change the rough frequency with which I see the problems. I
only added that directive for the port 80 virtual host, while the 443
virtual host doesn't have it. Should I add it to both?
Thanks,
Alex
On Apr 30, 1:47 am, Graham Dumpleton graham.dumple...@gmail.com
wrote:
2009/4/18 Alex Robbins alexander.j.robb...@gmail.com:
When you say 'Also, I get no errors if I remove the maximum-requests',
is that on all configurations?
Yes, that fixes it in all of the cases.
When you run your tests, are requests always sequential? Ie., no
concurrent requests.
No, the url checker is threaded, it normally runs 10 concurrent
threads, each making a urllib.open call, printing the status code if
not 200, then terminating.
Does it make a difference if you specify:
WSGIApplicationGroup %{GLOBAL}
Not sure, home sick today so I can't try it.
Finally, what other third party C extension modules do you use besides
GeoDjango? Ie., databases, etc. Do you use ctypes module?
We are using the mysql backend (mysqldb I think) and Pycrypto.
No ctypes, and we don't use GeoDjango
Also, those pages don't use any crypto, that is only for credit card
stuff or transaction submission.
Any update on whether:
WSGIApplicationGroup %{GLOBAL}
made a difference or not?
Graham
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
modwsgi group.
To post to this group, send email to modwsgi@googlegroups.com
To unsubscribe from this group, send email to
modwsgi+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/modwsgi?hl=en
-~--~~~~--~~--~--~---
[modwsgi] Re: Intermittent NoReverseMatch errors
2009/5/7 Alex Robbins alexander.j.robb...@gmail.com:
They are using different processes, doesn't that separate them?
Even if you have setup distinct WSGIDaemonProcess for each
virtualhost/port, you still want to force both to run in main
interpreter.
BTW, it is possible to get them to run in the same process using:
VirtualHost *:80
ServerName foo.com
WSGIDaemonProcess myapp .
WSGIApplicationGroup %{GLOBAL}
WSGIProcessGroup myapp
/VirtualHost
VirtualHost *:443
ServerName foo.com
WSGIApplicationGroup %{GLOBAL}
WSGIProcessGroup myapp
/VirtualHost
This is because WSGIProcessGroup can reference a daemon process group
for same server name even if marked against virtual host for different
port. The WSGIDaemonProcess should be in first VirtualHost by order,
although 2.X probably doesn't enforce that, in 3.X the ordering
requirement will be enforced.
Doing this you can cut down number of processes. There is no harm
derived from having both http and https requests handled in same
daemon process group.
Graham
On May 3, 12:00 am, Graham Dumpleton graham.dumple...@gmail.com
wrote:
If you are receiving requests for same application on both ports, then yes.
Graham
2009/5/2 Alex Robbins alexander.j.robb...@gmail.com:
Sorry this reply took so long, I am in the middle of changing jobs.
Anyway,
WSGIApplicationGroup %{GLOBAL}
does not change the rough frequency with which I see the problems. I
only added that directive for the port 80 virtual host, while the 443
virtual host doesn't have it. Should I add it to both?
Thanks,
Alex
On Apr 30, 1:47 am, Graham Dumpleton graham.dumple...@gmail.com
wrote:
2009/4/18 Alex Robbins alexander.j.robb...@gmail.com:
When you say 'Also, I get no errors if I remove the maximum-requests',
is that on all configurations?
Yes, that fixes it in all of the cases.
When you run your tests, are requests always sequential? Ie., no
concurrent requests.
No, the url checker is threaded, it normally runs 10 concurrent
threads, each making a urllib.open call, printing the status code if
not 200, then terminating.
Does it make a difference if you specify:
WSGIApplicationGroup %{GLOBAL}
Not sure, home sick today so I can't try it.
Finally, what other third party C extension modules do you use besides
GeoDjango? Ie., databases, etc. Do you use ctypes module?
We are using the mysql backend (mysqldb I think) and Pycrypto.
No ctypes, and we don't use GeoDjango
Also, those pages don't use any crypto, that is only for credit card
stuff or transaction submission.
Any update on whether:
WSGIApplicationGroup %{GLOBAL}
made a difference or not?
Graham
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
modwsgi group.
To post to this group, send email to modwsgi@googlegroups.com
To unsubscribe from this group, send email to
modwsgi+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/modwsgi?hl=en
-~--~~~~--~~--~--~---
[modwsgi] Re: Intermittent NoReverseMatch errors
If you are receiving requests for same application on both ports, then yes.
Graham
2009/5/2 Alex Robbins alexander.j.robb...@gmail.com:
Sorry this reply took so long, I am in the middle of changing jobs.
Anyway,
WSGIApplicationGroup %{GLOBAL}
does not change the rough frequency with which I see the problems. I
only added that directive for the port 80 virtual host, while the 443
virtual host doesn't have it. Should I add it to both?
Thanks,
Alex
On Apr 30, 1:47 am, Graham Dumpleton graham.dumple...@gmail.com
wrote:
2009/4/18 Alex Robbins alexander.j.robb...@gmail.com:
When you say 'Also, I get no errors if I remove the maximum-requests',
is that on all configurations?
Yes, that fixes it in all of the cases.
When you run your tests, are requests always sequential? Ie., no
concurrent requests.
No, the url checker is threaded, it normally runs 10 concurrent
threads, each making a urllib.open call, printing the status code if
not 200, then terminating.
Does it make a difference if you specify:
WSGIApplicationGroup %{GLOBAL}
Not sure, home sick today so I can't try it.
Finally, what other third party C extension modules do you use besides
GeoDjango? Ie., databases, etc. Do you use ctypes module?
We are using the mysql backend (mysqldb I think) and Pycrypto.
No ctypes, and we don't use GeoDjango
Also, those pages don't use any crypto, that is only for credit card
stuff or transaction submission.
Any update on whether:
WSGIApplicationGroup %{GLOBAL}
made a difference or not?
Graham
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
modwsgi group.
To post to this group, send email to modwsgi@googlegroups.com
To unsubscribe from this group, send email to
modwsgi+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/modwsgi?hl=en
-~--~~~~--~~--~--~---
[modwsgi] Re: Intermittent NoReverseMatch errors
Sorry this reply took so long, I am in the middle of changing jobs.
Anyway,
WSGIApplicationGroup %{GLOBAL}
does not change the rough frequency with which I see the problems. I
only added that directive for the port 80 virtual host, while the 443
virtual host doesn't have it. Should I add it to both?
Thanks,
Alex
On Apr 30, 1:47 am, Graham Dumpleton graham.dumple...@gmail.com
wrote:
2009/4/18 Alex Robbins alexander.j.robb...@gmail.com:
When you say 'Also, I get no errors if I remove the maximum-requests',
is that on all configurations?
Yes, that fixes it in all of the cases.
When you run your tests, are requests always sequential? Ie., no
concurrent requests.
No, the url checker is threaded, it normally runs 10 concurrent
threads, each making a urllib.open call, printing the status code if
not 200, then terminating.
Does it make a difference if you specify:
WSGIApplicationGroup %{GLOBAL}
Not sure, home sick today so I can't try it.
Finally, what other third party C extension modules do you use besides
GeoDjango? Ie., databases, etc. Do you use ctypes module?
We are using the mysql backend (mysqldb I think) and Pycrypto.
No ctypes, and we don't use GeoDjango
Also, those pages don't use any crypto, that is only for credit card
stuff or transaction submission.
Any update on whether:
WSGIApplicationGroup %{GLOBAL}
made a difference or not?
Graham
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
modwsgi group.
To post to this group, send email to modwsgi@googlegroups.com
To unsubscribe from this group, send email to
modwsgi+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/modwsgi?hl=en
-~--~~~~--~~--~--~---
[modwsgi] Re: Intermittent NoReverseMatch errors
When you say 'Also, I get no errors if I remove the maximum-requests',
is that on all configurations?
Yes, that fixes it in all of the cases.
When you run your tests, are requests always sequential? Ie., no
concurrent requests.
No, the url checker is threaded, it normally runs 10 concurrent
threads, each making a urllib.open call, printing the status code if
not 200, then terminating.
Does it make a difference if you specify:
WSGIApplicationGroup %{GLOBAL}
Not sure, home sick today so I can't try it.
Finally, what other third party C extension modules do you use besides
GeoDjango? Ie., databases, etc. Do you use ctypes module?
We are using the mysql backend (mysqldb I think) and Pycrypto.
No ctypes, and we don't use GeoDjango
Also, those pages don't use any crypto, that is only for credit card
stuff or transaction submission.
Thanks,
Alex
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
modwsgi group.
To post to this group, send email to modwsgi@googlegroups.com
To unsubscribe from this group, send email to
modwsgi+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/modwsgi?hl=en
-~--~~~~--~~--~--~---
[modwsgi] Re: Intermittent NoReverseMatch errors
The urls that not working aren't using anything except the plain django 1.0.2. (No GeoDjango). So it could be django. How would increasing the max requests make it more thread-safe? On Apr 15, 4:03 pm, Ariel Mauricio Nunez Gomez ingenieroar...@gmail.com wrote: Bah, I didn't realize it was an old thread, the OP must have solved his issue by now. Alex, are you using any library that is not thread safe? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups modwsgi group. To post to this group, send email to modwsgi@googlegroups.com To unsubscribe from this group, send email to modwsgi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en -~--~~~~--~~--~--~---
[modwsgi] Re: Intermittent NoReverseMatch errors
When you say 'Also, I get no errors if I remove the maximum-requests',
is that on all configurations?
When you run your tests, are requests always sequential? Ie., no
concurrent requests.
Does it make a difference if you specify:
WSGIApplicationGroup %{GLOBAL}
Finally, what other third party C extension modules do you use besides
GeoDjango? Ie., databases, etc. Do you use ctypes module?
Graham
2009/4/16 Alex Robbins alexander.j.robb...@gmail.com:
The urls that not working aren't using anything except the plain
django 1.0.2. (No GeoDjango). So it could be django. How would
increasing the max requests make it more thread-safe?
On Apr 15, 4:03 pm, Ariel Mauricio Nunez Gomez
ingenieroar...@gmail.com wrote:
Bah, I didn't realize it was an old thread, the OP must have solved his
issue by now.
Alex, are you using any library that is not thread safe?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
modwsgi group.
To post to this group, send email to modwsgi@googlegroups.com
To unsubscribe from this group, send email to
modwsgi+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/modwsgi?hl=en
-~--~~~~--~~--~--~---
[modwsgi] Re: Intermittent NoReverseMatch errors
I'm going to try your suggestion (single threaded, multiprocess) and see what happens. Remember process are expensive, so start with a low number and increase as needed. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups modwsgi group. To post to this group, send email to modwsgi@googlegroups.com To unsubscribe from this group, send email to modwsgi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en -~--~~~~--~~--~--~---
[modwsgi] Re: Intermittent NoReverseMatch errors
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 graham.dumple...@gmail.com wrote: 2009/3/19 Graham Dumpleton graham.dumple...@gmail.com: 2009/3/19 Pete sgt.hu...@gmail.com: On Mar 18, 3:35 pm, Graham Dumpleton graham.dumple...@gmail.com 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 modwsgi@googlegroups.com To unsubscribe from this group, send email to modwsgi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en -~--~~~~--~~--~--~---
[modwsgi] Re: Intermittent NoReverseMatch errors
Also, I get no errors if I remove the maximum-requests On Apr 15, 3:45 pm, Alex Robbins alexander.j.robb...@gmail.com 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 graham.dumple...@gmail.com wrote: 2009/3/19 Graham Dumpleton graham.dumple...@gmail.com: 2009/3/19 Pete sgt.hu...@gmail.com: On Mar 18, 3:35 pm, Graham Dumpleton graham.dumple...@gmail.com 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 modwsgi@googlegroups.com To unsubscribe from this group, send email to modwsgi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en -~--~~~~--~~--~--~---
[modwsgi] Re: Intermittent NoReverseMatch errors
Pete, That could happen if you are using GeoDjango, unhandled exceptions would come up now and then if you are using multiple threads but they would be masked out by reverse url errors in templates. I cannot tell for sure because you masked out your site name with ServerName project.com But your log: [Tue Mar 17 01:07:44 2009] [info] mod_wsgi (pid=8162): Enable monitor thread in process 'trailmapping'. Led me to http://trailmapping.com/ And I assume you do use GeoDjango. The solution is to run single threaded, multiprocess. Regards, Ariel. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups modwsgi group. To post to this group, send email to modwsgi@googlegroups.com To unsubscribe from this group, send email to modwsgi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en -~--~~~~--~~--~--~---
[modwsgi] Re: Intermittent NoReverseMatch errors
Bah, I didn't realize it was an old thread, the OP must have solved his issue by now. Alex, are you using any library that is not thread safe? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups modwsgi group. To post to this group, send email to modwsgi@googlegroups.com To unsubscribe from this group, send email to modwsgi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en -~--~~~~--~~--~--~---
[modwsgi] Re: Intermittent NoReverseMatch errors
On Mar 18, 3:35 pm, Graham Dumpleton graham.dumple...@gmail.com 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? If not, is it possible for unexpected behavior to occur if we try to access the app during the wsgi script load process? -- Pete --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups modwsgi group. To post to this group, send email to modwsgi@googlegroups.com To unsubscribe from this group, send email to modwsgi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en -~--~~~~--~~--~--~---
[modwsgi] Re: Intermittent NoReverseMatch errors
2009/3/19 Pete sgt.hu...@gmail.com: On Mar 18, 3:35 pm, Graham Dumpleton graham.dumple...@gmail.com 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 using maximum requests option? 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. Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups modwsgi group. To post to this group, send email to modwsgi@googlegroups.com To unsubscribe from this group, send email to modwsgi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en -~--~~~~--~~--~--~---
[modwsgi] Re: Intermittent NoReverseMatch errors
2009/3/19 Graham Dumpleton graham.dumple...@gmail.com: 2009/3/19 Pete sgt.hu...@gmail.com: On Mar 18, 3:35 pm, Graham Dumpleton graham.dumple...@gmail.com 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 using maximum requests option? 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=1 maximum-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 modwsgi@googlegroups.com To unsubscribe from this group, send email to modwsgi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en -~--~~~~--~~--~--~---
