When using multiple processes, each process will have its own copy of tg.app_globals. When using multiple threads instead, the threads will share the same tg.app_globals and you should avoid writing there after bootstrap.
See http://turbogears.readthedocs.org/en/latest/cookbook/deploy/mod_wsgi.html for a guide on running TG under mod_Wsgi. On Mon, Apr 13, 2015 at 6:10 PM, Ernie Lee <[email protected]> wrote: > Thank you for info Alessandro! I was indeed tried to use gearbox. I will > see if 'waitress' package and wsgiref.threaded option helps. > > Related question: i was investigating Apache mod-wsgi as hosting solution > and documentation suggests using at least two Apache daemon processes so > one can continue to serve pages while other being restarted. However my > application uses TG app_globals, will it work correctly when deployed with > two processes using mod_wsgi? Or will i ends up with two processes, both > having its own copies of app_globals objects? > > (if this will work correctly, i am curious how is this implemented?) > > Thanks, > > Ernie. > > On Sun, Apr 12, 2015 at 7:24 AM, Alessandro Molina < > [email protected]> wrote: > >> Are you trying to use gearbox#wsgiref for production? >> >> Using egg:gearbox#wsgiref in [server:main] is greatly discouraged, that >> is a development only single process, single thread HTTP/1.0 server. As you >> can guess if one for your clients leaves the connection open (or doesn't >> properly terminate it) you will end up with the single thread being blocked >> on waiting for that client and unable to satisfy other requests. >> >> If you want to go with a simple plain python solution I suggest you try >> egg:waitress#main (provided by waitress package), otherwise if you need to >> totally avoid other packages at least enable the "wsgiref.threaded = true" >> options insid [server:main] as documented by >> https://github.com/TurboGears/gearbox#gearbox-http-servers That will >> provide a multithreaded server forking a thread for each request. It's >> highly inefficient when compared to a thread pool based server, but will at >> least prevent a single client from blocking the entire webapp. >> >> On Wed, Apr 8, 2015 at 10:53 PM, <[email protected]> wrote: >> >>> Hi there, >>> >>> I am trying to use TG Gearbox for production site and encounter the >>> following problem: when i am trying to open many pages at once and abruptly >>> terminate connections my server will freeze and stop responding without >>> coming back (manual restart of gearbox is needed). The same occur if i just >>> let my web site run for a while. >>> >>> When such freezing happened attempt to retrieve index page from server >>> machine itself with wget give me following output (see below) - so it looks >>> like connection got accepted but no response process run (it will >>> eventually terminate with timeout error). Also: the page that my wget >>> script tries to retrieve is static page from public/ dir so it does not >>> require DB access. Therefor i doubt that database issues is responsible for >>> this problem. >>> >>> What will be the best way to debug this? I have tried to look at the >>> logs but nothing unusual is logged just before the freezing occur. Is there >>> is any config options that i should try to tweak? >>> >>> Also, am i wrong in my attempt of using gearbox for production site? >>> Was it intended for debug/devel only? And therefor should i just try >>> switching to Apache instead? Using Gearbox is quite convenient because i >>> can see all the error messages printed so i would like to continue using it >>> if possible. >>> >>> Thank you, >>> >>> Ernie. >>> >>> --2015-04-08 16:33:46-- http://127.0.0.1:8092/myfiles/test >>> Connecting to 127.0.0.1:8092... connected. >>> HTTP request sent, awaiting response... >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "TurboGears" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To post to this group, send email to [email protected]. >>> Visit this group at http://groups.google.com/group/turbogears. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "TurboGears" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/turbogears/hjCaGfXJ6Qc/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at http://groups.google.com/group/turbogears. >> For more options, visit https://groups.google.com/d/optout. >> > > -- > You received this message because you are subscribed to the Google Groups > "TurboGears" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/turbogears. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "TurboGears" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/turbogears. For more options, visit https://groups.google.com/d/optout.
