On 13/01/2010 03:24, Graham Dumpleton wrote:
Not a lot, but jogged my memory over what this may be. It has come up
once, maybe twice before only and is in part why mod_wsgi was changed
to generate a timeout like that.
What was occurring in prior case, which was investigated a bit, was
that the Apache server child process was getting a successful result
for connecting to the listener socket of the daemon process and so
started proxying the request, but on the daemon side it was never
getting any indication at all that a connection had been received and
hadn't even accepted a connection. Thus daemon process was just
sitting there not doing anything yet the Apache server child process
was waiting for a response.
In the main case where this happened before it was only happening
every so often and not every time as seems to be your case. There was
suspicion over another case like yours where it happened every time
but don't remember the outcome of that. It is possible they just gave
up and went away without providing opportunity to debug it, or that
they rebuilt lots of stuff and it went away, I just can't remember.
One discussion about prior issue is:
http://groups.google.com/group/trac-dev/browse_frm/thread/bcaedbbb7fe5b6c
Unfortunately people don't always get back to me about whether issue
indeed went away or what they worked out the problem was. In this case
all I could do was to patch the code to make it more tolerant of
unexpected behaviour.
Give me a little while to think about this. I may put some more
debugging in code and get you to compile up a version from head of
subversion repository.
Graham
Hi Graham,
Once again, thanks for this.
After spending a couple of hours setting up a pristine jail to test it
all, I was hoping the problem would just go away when I tried running
the example code in it. However, I was again frustrated by failure.
I tried another couple of things but still nothing. Then, really by
chance, I mentioned the annoying problem to a fellow FreeBSD person and
he told me what mod_wsgi configuration settings he was using on his
system, allowing me to compare with him what I was using.
I tried removing and adding things from the config to match up with his,
and after a few attempts I finally figured out what was causing the
problem. Basically by changing 'display-name=%{GROUP}' to
'display-name=arbitrarystring' and completely removing the
'WSGIProcessGroup test.elasticmind.net' line, it magically started working.
I think for some reason I thought 'WSGIProcessGroup' could be called
anything I wanted so I was using the domain name of the vhost. But
reading a bit about that directive suggests that this is not how it
works and it actually needs something special (although I'm not entirely
sure what). In a number of example configurations I see the
WSGIProcessGroup directive being used, but having just read the
Configuration Directives information on it, I'm not really sure what its
benefits are and why that is so - considering the problems it has caused
for me (although admittedly I'm really tired so I wouldn't be surprised
if my head is having a little trouble assimilating that information
right now, heh).
Does that make sense at all?
Kind regards,
mog
--
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.
