On Tuesday, July 17, 2018 at 7:46:59 PM UTC-4, Bert JW Regeer wrote: > > The threads that run the WSGI app are pre-spawned, they wait on a new > request to be added to a queue, peel one off, pass it down the WSGI app, > and then back. > ... > What are you trying to do with a "max requests"? >
Thanks for all the above. It answers all my questions about how waitress works. Several web servers implement a concept of "max number of cumulative requests each subprocess can serve" before that subprocess (thread or fork) is terminated and replaced with a new process. The situation I'm trying to debug has to do with some unpredicted behavior and a particular 'constant' variable that is assigned during the application initialization, and (should only be) read afterwards. It works fine initially, then seems to 'unset' to a default value after an hour or so. I want to ensure the error isn't being triggered when 'max requests' is hit and a new subprocess being spawned. I don't think it is, but I'd like to be sure. It's been a pain trying to recreate this scenario with uwsgi/nginx and apache/mod_wsgi. -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to pylons-discuss+unsubscr...@googlegroups.com. To post to this group, send email to pylons-discuss@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/pylons-discuss/0d72eb02-4ef8-4f27-8e9a-616db185156b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
