> On Jul 17, 2018, at 22:40, Jonathan Vanasco <jvana...@gmail.com> wrote:
> 
> 
> 
> 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.

If it is a forking() server, I would think they create the WSGI app once, and 
then upon forking the children just use that same one rather than re-initialise 
the whole WSGI app for each child it forks, but I may be wrong.

Either way, I don't see how after an hour it would suddenly become unset, 
because either it forks from the original, and re-uses, in which case it should 
be initialised, or it re-initialises the whole WSGI app from scratch, at which 
point it should be set to the non-default.

> 
> 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 
> <mailto:pylons-discuss+unsubscr...@googlegroups.com>.
> To post to this group, send email to pylons-discuss@googlegroups.com 
> <mailto: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
>  
> <https://groups.google.com/d/msgid/pylons-discuss/0d72eb02-4ef8-4f27-8e9a-616db185156b%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
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/319C4D59-BEB9-438F-84B4-3F1311822F32%400x58.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to