2009/5/7 Alex Robbins :
>
> 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:
They are using different processes, doesn't that separate them?
On May 3, 12:00 am, Graham Dumpleton
wrote:
> If you are receiving requests for same application on both ports, then yes.
>
> Graham
>
> 2009/5/2 Alex Robbins :
>
>
>
> > Sorry this reply took so long, I am in the middle of changing
If you are receiving requests for same application on both ports, then yes.
Graham
2009/5/2 Alex Robbins :
>
> 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
>
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 bo
2009/4/18 Alex Robbins :
>
>> 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
> 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 concur
> 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 Goog
On Wed, Apr 15, 2009 at 3:03 PM, Ariel Mauricio Nunez Gomez
wrote:
> Bah, I didn't realize it was an old thread, the OP must have solved his
> issue by now.
Interesting. Yes, we are using GeoDjango. I haven't solved the issue,
but haven't had much time to troubleshoot lately and get back. I'm
go
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
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
wrote:
> Bah, I didn't realize it was an old thread, the OP must ha
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
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 yo
Also, I get no errors if I remove the maximum-requests
On Apr 15, 3:45 pm, Alex Robbins
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) o
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 mor
2009/3/19 Graham Dumpleton :
> 2009/3/19 Pete :
>>
>> On Mar 18, 3:35 pm, Graham Dumpleton
>> 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 reference
2009/3/19 Pete :
>
> On Mar 18, 3:35 pm, Graham Dumpleton
> 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
On Mar 18, 3:35 pm, Graham Dumpleton
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 ha
2009/3/19 Pete :
>
> I'm running mod_wsgi 2.3 in daemon mode behind an Nginx proxy. Every
> day or two I see unrepeatable errors like this:
>
> NoReverseMatch: Reverse for 'project.url_name' with arguments '()' and
> keyword arguments '{}' not found.
This is not an error from mod_wsgi but from Dj
18 matches
Mail list logo
