Hi Graham, Yeah, I just wanan know if multiple threads in daemon mode works okay with either prefork or worker MPM. Thanks!
-peter On Fri, Aug 6, 2010 at 12:11 PM, Graham Dumpleton < [email protected]> wrote: > On 6 August 2010 14:00, Peter Yen <[email protected]> wrote: > > Hi Graham, > > > > Thanks for your response and feedback. That really makes me plan to > re-learn > > the wiki and pay more attention to implication on directives. > > > > Set to WSGIApplicationGroup %{GLOBAL}, makes mod_wsgi 3.3 works. and I've > > changed the eggs to a secure place and disable the processes flag. > > > > Is there any concern if using apache worker MPM with WSGI daemon mode > with > > threaded properties? > > Not sure I understand the question. > > Multiple threads in daemon mode work fine if using either prefork or > worker MPM in Apache. > > The only requirement is that when using prefork MPM, the underlying > APR libraries must have thread support compiled into them. > > Also, your code should also be thread safe. > > Obviously how many threads to use is a topic involving much hand > waving, as well as lots of smoke and mirrors as it depends on so many > factors. > > Anyway, as I said, not sure what exactly you are wanting to know. > > Graham > > > Thanks for all the help. > > > > > > -peter > > > > > > On Fri, Aug 6, 2010 at 11:12 AM, Graham Dumpleton > > <[email protected]> wrote: > >> > >> 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]<modwsgi%[email protected]> > . > >> >> > For more options, visit this group > >> >> > athttp://groups.google.com/group/modwsgi?hl=en. > >> >> > >> >> > > > > > > > > -- > > mobile: 0963499558 > > Pinkoi.com > > > -- mobile: 0963499558 Pinkoi.com -- 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.
