Please use reply-all and keep followups on mailing list.
On 6 August 2010 13:05, colorpyen <[email protected]> wrote:
> Hi Graham,
>
> Thanks for your quick response. My DaemonProcess directive is listed
> below. I didn't try to override the deadlock timeout as it didn't
> cause any problem in wsgi3.0c. I tried to downgrade wsgi to 2.8 and
> now it works okay. But I am still curious about why the deadlock
> problem may cause. Any C extension you can think of as it may
> introduce the problem. I use PIL 1.7 and Lxml.
The lxml package has had known problems working in Python sub
interpreters in the past.
Try with mod_wsgi 3.3, but add:
WSGIApplicationGroup %{GLOBAL}
to force use of main Python interpreter.
If you are hosting multiple WSGI applications, you will want to
restrict that directive to context of that specific application, or
ensure that each application is run in its own daemon process group to
ensure separation in case framework being used cant handle multiple
instances running in same interpreter.
Forcing use of main interpreter will avoid potential for issues where
packages not compatible with sub interpreters.
> Is overriding deadlock timeout introducing any performance degradation
> if set?
>
> WSGIDaemonProcess koistore processes=1
Don't set 'processes=1', let it default to '1'. Use of the 'processes'
option, no matter the value, flags to WSGI application that it is
running across multiple processes. Triggering that prevents things
which expect to run in a single process, and check that value, from
working.
> threads=5 display-name=%
> {GROUP} \
> home=/var/www/koistore \
> python-path=/usr/local/pythonenv/DJANGO/lib/
> python2.6/site-packages \
> python-eggs=/tmp/python-eggs
It is generally a bad idea to put Python eggs cache in /tmp, at least
on systems where server used by different users.
Graham
> # process group that serves this WSGI application in the virtual
> host
> WSGIProcessGroup koistore
>
> Thanks a lot
>
> -peter
>
> On Aug 6, 7:45 am, Graham Dumpleton <[email protected]>
> wrote:
>> On 6 August 2010 05:15, colorpyen <[email protected]> wrote:
>>
>> > some interesting logs
>>
>> > [info] mod_wsgi (pid=12985): Daemon process deadlock timer expired,
>> > stopping process 'koistore'.
>>
>> What are the WSGIDaemonProcess directive options you are using?
>>
>> That message above implies that some code in the application, normally
>> a C extension module, acquired the Python GIL and then did a long
>> operation which blocks, without releasing the GIL.
>>
>> The default deadlock timeout is 5 minutes however, so that the daemon
>> process wasn't processing other requests should have been noticeable.
>>
>> Have you overridden the default deadlock timeout?
>>
>> Graham
>>
>> > [Fri Aug 06 02:46:12 2010] [info] mod_wsgi (pid=12985): Shutdown
>> > requested 'koistore'.
>> > [Fri Aug 06 02:46:17 2010] [info] mod_wsgi (pid=12985): Aborting
>> > process 'koistore'.
>> > [Fri Aug 06 02:46:17 2010] [error] [client 114.32.30.80] Premature end
>> > of script headers: application.wsgi, referer:http://apps.facebook
>> > [Fri Aug 06 02:46:17 2010] [info] mod_wsgi (pid=13088): Attach
>> > interpreter ''.
>> > [Fri Aug 06 02:46:17 2010] [info] mod_wsgi (pid=13088): Adding '/usr/
>> > local/pythonenv/DJANGO/lib/python2.6/site-packages' to path.
>> > [Fri Aug 06 02:46:17 2010] [info] mod_wsgi (pid=13088): Create
>> > interpreter 'www.evermai.com|'.
>> > [Fri Aug 06 02:46:17 2010] [info] mod_wsgi (pid=13088): Adding '/usr/
>> > local/pythonenv/DJANGO/lib/python2.6/site-packages' to path.
>> > [Fri Aug 06 02:46:17 2010] [info] [client 220.181.94.226] (32)Broken
>> > pipe: core_output_filter: writing data to the network
>> > [Fri Aug 06 02:46:17 2010] [info] [client 220.181.94.226] mod_wsgi
>> > (pid=13088, process='koistore', application='www.evermai.com|'): Loadi
>> > [Fri Aug 06 02:46:18 2010] [info] [client 220.181.94.226] (32)Broken
>> > pipe: core_output_filter: writing data to the network
>> > [Fri Aug 06 02:46:18 2010] [info] [client 220.181.94.226] (32)Broken
>> > pipe: core_output_filter: writing data to the network
>> > [Fri Aug 06 02:46:18 2010] [info] [client 220.181.94.226] (32)Broken
>> > pipe: core_output_filter: writing data to the network
>> > [Fri Aug 06 02:46:18 2010] [info] [client 114.45.139.105] (32)Broken
>> > pipe: core_output_filter: writing data to the network
>> > [Fri Aug 06 02:46:18 2010] [error] [client 220.181.94.226] Script
>> > timed out before returning headers: application.wsgi
>>
>> > On Aug 6, 3:05 am, colorpyen <[email protected]> wrote:
>> >> I have been using wsgi3.0c in daemon for almost a year and recently
>> >> upgraded to 3.3. Strange is now the server is not responding?
>>
>> >> Any help is appreciated.!!
>>
>> >> // server version
>> >> Apache/2.2.14 (Ubuntu) mod_wsgi/3.3 Python/2.6.5
>>
>> >> [Fri Aug 06 03:02:15 2010] [error] [client 220.181.94.226] Script
>> >> timed out before returning headers: application.wsgi
>>
>> >> Thanks a lot.
>>
>> >> -peter
>>
>> > --
>> > 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
>> > athttp://groups.google.com/group/modwsgi?hl=en.
>>
>>
--
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.
