> WSGIApplication %{GLOBAL}
You meant "WSGIApplicationGroup %{GLOBAL}"
I totally forgot about the sub interpreter issues. I haven't had any
troubles with pymongo and subinterpreters in the past. Setting the
Application Group to Global helped for Trac installations, but
unfortunately in this case it doesn't change a thing.
> The mod_wsgi code does send SIGINT's to itself, but messages would
> have to imply that it is getting stuck in some sort of loop to be
> continually sending them to itself. The only place I could see that
> easily happening is if in the monitor thread, which is what handles
> deadlock timeout etc. Not sure how it could go haywire though and
> cause a rapid SIGINT loop. Worst case it should only generate a SIGINT
> once a second and that only in a state where the main thread which is
> waiting on reading off that fd=5 of socketpair was failing to read the
> "X" and not exit the process. It would take something closing and
> replacing fd=5 to really screw with that.
The SIGINT loop is not rapid. It occurs about once per second but
doesn't stop. Apache log stays quiet. After some time Apache reports a
timed out request. The WSGI daemon stays unuseable and the only way to
fix it is to reload/restart Apache or kill -9 the WSGI daemon.
> LogLevel debug
>
> and:
>
> WSGIVerboseDebugging On
Right now we depend on a working setup so we simply disabled the C
extensions of pymongo. This fixed the issue for us. I'll try to dig
deeper into this issue in the future as we would prefer to use pymongo
with the C extension enabled.
Thanks for the help,
Michael
--
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.
